"Context-sensitive" permissions

"Context-sensitive" permissions

  

Hello everybody,

we are currently evaluating OutSystems for use in a big software project. In this project, we need to be able to express permissions like that: "The current user is allowed to read project records where she is the project leader". Or, one step more complex: "The current user is allowed to delete a workitem only in projects where she is the project leader". I could not really understand if this is possible in OutSystems. Can anybody help me?

Kind regards,
Markus
The Outsystems platform, like most other software development platforms, provides the tools you need to do this but it's almost all in how you design the database.  Even if you use the built in Roles and Groups, you must still define the relationship between projects and individuals and define the organizational hierarchy.  The later is needed so you can 'show all project for which <name> is a project manager'.  Assuming you have a competent database designer this would work exactly the same as any other platform.

Hope this helps,
Curt
Suggest you do the following:

?1. Wrap all CRUD actions in a data access layer.
?2. In the data access layer, use the functions like "CheckXYZRole()" (each role you make gets an action like that made) to validate that the current user has the permissions you require if you are using roles, or do a lookup against a table (check to see if the current user is the "project leader" or whatever) and throw an exception or otherwise fail if the user does not have the needed permissions.

?J.Ja
Hi Curt!
thank you for your reply. Please excuse if I am asking trivial things, but I am a littl bit overwhelmed by the huge amount of available documentation. I could, until now, only find documentation about how I can express read restrictions on a role-enetity base (role X is not allowed to read entities of type Y). As said, I need to express such restrictions with conditions. Can you perhaps give me a hint where I can find documentation about this or where in the product I should look to get a deeper insight?

Kind regards,
Markus

Curt Raddatz wrote:
The Outsystems platform, like most other software development platforms, provides the tools you need to do this but it's almost all in how you design the database.  Even if you use the built in Roles and Groups, you must still define the relationship between projects and individuals and define the organizational hierarchy.  The later is needed so you can 'show all project for which <name> is a project manager'.  Assuming you have a competent database designer this would work exactly the same as any other platform.

Hope this helps,
Curt
 
 

Hi Justin,

as far as I understand your suggestion, I will have to know all roles at design time, as I have to provide the check-function for each of these roles. Is this correct? If so, I can not implement this, as in our product, the customers define the permission rules.
Nevertheless, I have a question: The CRUD operations are generated by the framework, right? How can I wrap them? Can this be done in a generic way, or must I write the wrapper for each operation manually?

Kind reagrds,
Markus
Markus - you said you need express such restrictions as conditions.  Yes, that's exactly right.  In your logic you need to use 'If' blocks (see help for more info) and if the user fails the condition, display an error, reroute to a different screen or perform some other action.

Since you want all this to be dynamic you would NOT use the built-in Roles and Groups, just design entities to hold the data you need that would allow clients to define these.  Again, this is no different than implementing this on any other platform.

Hope this helps,
Curt

Markus -

It is a very common design pattern to do the following:

* Put your entities in a data espace.
* Set them to "Public" = "Yes" and "Expose Read Only" = "Yes"
* Create Actions to provide insert/update and delete functionality that works the way you want it to, make those public. For example, a "delete" Action might not actually run "delete" it could set "IsActive" = "False" and save it. These actions usually do things like set an updated (or created) on timestamp and user ID, validate any business logic or data integrity issues before trying to save or delete, provide friendly "plain English" error messages instead of letting the SQL fail and give an ugly error message, etc.

This is NOT an OutSystems-specific pattern, it is a general programming "best practice" pattern, and I highly recommend it. The downside is that you cannot easily drag/drop screens together, but if you set it to be "read only" = "no", you can drag/drop screens properly again, then flip it back and change the uses of the built-in CRUD commands with your new actions.

It is a much better way of doing things.

J.Ja

Hello both of you,

thank you very much for your explanations!