Where Should I Put My Application’s Roles in OutSystems?
This question recently crossed my path, and it was great timing since I have recently released my Application Framework which incorporates this pattern into it. For the sake of this discussion, we are using “application” to refer to a full, complete program or application not the unit of code organization that OutSystems calls an “Application”.
Make a Module dedicated to “Security” that has not much more than Roles in it, and some helper Actions related to Roles.
Explanation
What are the options we have?
A. Each discrete piece of functionality has its own Roles in one of its Modules
B. In the application’s theme
C. One single place to store the Roles for the entire application
Why choose C?
“No circular references” is a key commandment in application development, particularly in OutSystems. A circular reference can and will sink you badly. It’s what I call an “immovable requirement”, one that, if someone violates it there should be extreme counseling to ensure it does not happen again, and if anyone deliberately suggests that you violate it, anyone in the organization should be able to escalate directly to the top of the organization to push back against it.
A Is Bad
If we take choice A, we will quickly end up with side references (not awful by themselves), but side references often become circular references. When they do become circular references, it usually is a surprise to us… what was a nice, polite side reference suddenly becomes the circular reference monster in short order, all it takes it one new requirement and… wham. So choosing A may work out today but it is like planting a poison ivy bush in an unused corner of your yard and saying, “hey, no one ever goes in that part of the lawn anyways, it’s OK!” One day it won’t be, and that is very predictable.
Even worse for A, in many (most?) applications of an appreciable size, you eventually want a nice way to group and list and consolidate all of the Roles in a single list so that you can make a nice, friendly user management system (no, “Users” does not count as a “nice, friendly user management system”), and if the Roles are scattered to the four winds, it won’t work out too well. If all your Modules are in the same Application you can munge a query together to do it, but if they are in separate Applications… fuhgeddaboudit. So A is out.
B Is WORSE
Consolidating all of the Roles in the application’s theme (we’ll ignore that virtually by definition, a “theme” should not be controlling security… oops I guess we aren’t ignoring that since I said it?) sounds like a good way to avoid the circular reference concern; it certainly will not cause any side references. But putting them in the theme is actually worse then spreading them around because you are virtually guaranteed to create a circular reference! Wait what how? Think about it for a second. Theme sits above business logic and data model, right? And don’t you need to use your Roles in your business logic and data model (perhaps to check permissions in your CRUD wrappers)? So there ya are, if you are building an application with enough “best practices” to care where your your Roles are kept, you are going to be making a circular reference between your theme and once of the Modules it should sit on top of in about, I dunno, 10 minutes? Let’s send B to /dev/null.
C Wins!
We need the Roles in a single Module to avoid side references and make it easy to enumerate, query, etc. those Roles. We need this single Module to sit so far at the bottom of the pyramid that there is no way it would ever have a circular reference, and we need it to do so insanely little that it would never put a side reference out or do anything to make a circular reference.
In other words, we need a module that does virtually nothing other than hold Roles.
If you look at the Module “ApplicationFramework_Security” in my Application Framework, you will see an example of exactly how this should be built. It has the Roles. It has a Static Entity representing the roles (because unfortunately, OutSystems won’t let me use a RoleId as an Attribute in a Static Entity like a menu system), and a few utility Actions, like a pair of Grant and Revoke Role Actions that let the RoleId be passed in as a parameter. (It is also a User Provider for the full application, to avoid the problems with Users.)
J.Ja
