Conditional Permissions
Last updated
Was this helpful?
Last updated
Was this helpful?
Conditional Permissions are configured as part of the . Object Class Permissions serve as the maximum permission a given Role may have towards a given Object Class (create, read, update or delete). With Conditional Permissions, you may grant conditional access for different Roles to different Object Classes, and it is an important concept when defining for a multi-tenant application.
As with normal Object Class Permissions, the Conditional Permissions are enforced server side (back end) and are tamper-proof as opposed to hiding data or UI using conditions inside your App.
The Role End Users have Read and Update permissions towards the Person Object Class, for users to update their own Person object from a view in an App.
However, on a permissions level on the back end, all End Users have access to all Person objects - not only their own record/object. Without Conditional Permissions, you must be very strict with filters and what data to load into your App.
With Conditional Permission, you may set up a rule that is enabled for End Users, only allowing you to read and update your own Person object.
This is a short guide on how to set up Conditional Permissions given a specific use case.
Consider the following Data Model
A logged-in User has an Person object. A Person belongs to a Company and may have a set of Person Documents. A Company may have a set of Orders.
We want to make sure
The user only has read access to the Person object (the one connected to the Current User) and the belonging Person Documents
The user only has access to the connected Company and the belonging Orders
For configuration of Conditional Permissions, go to Security -> Permissions -> Object Classes.
Clicking the Filter icon for the Person Object Class in the above screenshot opens a dialog for configuring the conditional Read-permissions for the Person Object Class.
Name: Optional, this is just a describing name for the rule
Enabled: This is where you set the condition on when this rule should apply. In this example, this rule should only apply when the logged-in user has the Role End user
Filter: The filter that always should be applied when reading Persons (enabled when ). In this case, always apply the filter Person.User = Current User.
Note that when Read permission has been set up conditionally for a given Role (or Roles), and some other Roles should have access to all, we need to add a rule for that as well. In the below screenshot, any user with a membership in any of the Roles Owner, Maintainer or Developers has read access to all Persons.
In other words: With Conditional Permissions set up, a user will get the sum of permissions defined by the rules in the setup above. If a user is both a Maintainer and an End User, the user will have read access to all Persons.
The same Enabled conditions and set of rules apply to this Object Class. But the Filter is different.
We need to define the path from Person Document to Current User, for the Read-permissions to work. The above screenshots illustrate how to set up a filter on all Person Documents belonging to a Person that the Current User is connected to.
For these permissions, we need to define a filter on all Companies belonging to the Person that the Current User is connected to.
In the above screenshot, the Person Object Class has the following filter:
For these permissions, we need to define a filter for all Orders belonging to the Companies of the Person object that the Current User is connected to. It is the same setup as for the Company permissions, except the left side of the filter (where Order.Company is the property we are filtering on).
