Security Elevation

Security elevation is about different permutations for a given user in regards to what that user can read, write, delete etc. based on what rights and permissions that user has. This wiki entry is a quick overview of possible permutations. This does not include all permutations but the common ones. Feel free to add to this article as needed.

For this example, we will use the account module.

User Jim is a regular user.
Without any rights or permissions Jim cannot do anything in the accounts module.

Rights – Add RIGHT_ACCESS_ACCOUNTS
At this point Jim, can view the listing page of accounts, although Jim will only see accounts he is the owner on. Jim cannot create new accounts. If Jim edits the accounts he owns, he can change the owner to another owner, but at that point Jim will lose the ability to read and write that account.

Remember, a user can always read and write models they own.

Rights – Add RIGHT_CREATE_ACCOUNTS
Jim can now create accounts.

Permissions – If there is an account owned by Sally, and you add explicit READ permissions for Jim on this account, then Jim can view this account. Jim can still not edit this account.

If you add explicit WRITE permissions on this account owned by Sally, then Jim can also edit the account as well as change permissions on the account. This is because in the user interface if you allow a user to edit a model, then the user can also change permissions. Under the cover these two separate permissions are combined together. It is possible though in the code to add WRITE, but not CHANGE_PERMISSIONS.

Next is Roles. The account Sally owns which Jim can read/write is called ‘ABC Company’. Jim has a boss Mary. Mary is the role of ‘Manager’, while Jim is in the role of ‘Associate’. If the Manager role is the parent role of the Associate role, then Mary too will be able to read/write ‘ABC Company’. Roles propagate permissions.

Next is Groups. The basic example of groups is if you have user A and user B part of group ‘Europe’. If you explicitly add group ‘Europe’ for Read permission on ‘ABC Company’, now user A and B can read ‘ABC Company’.

Continuing with groups, we will touch on nested groups. If group ‘Austria’ is a child group of ‘Europe’, any user in Austria can also read the ‘ABC Company’. But the ‘World’ group which is a parent group to ‘Europe’ does not do this. Only nested groups can propagate permissions upstream.

Leave a Comment

Mark

How would Sally add explicit read permissions for Jim on a given account? I can’t see to find the functionality in the demo.

Could someone elaborate this further?
What do you mean by a nested group?
What doesn’t the World group parent to Europe not do?

Laura Engel

Hello Dayson,

We do plan to rename things and potentially change the way groups and nested groups appear in the user interface to make things more clear. However, for the time being, and using the existing terminology, I will try to explain a bit more.

Using the same example as described in the wiki, you create 3 groups:

1. a Group called ‘World’.
2. a group called ‘Europe’, where the ‘Parent Group’ for Europe is ‘World’
3. a group called ‘Austria’, where the ‘Parent Group’ for Austria is ‘Europe’

In the Groups module, you then see something like this:
World
—–Europe
——– Austria

In this case, Austria is a nested group in relation to Europe, and Europe is a nested group of World.

When permissions propagate upstream, this means that the nested group can view the records of the groups above it:

If the read and write permissions for ‘ABC Company’ are set to World,
this means that users in the Austria group, the Europe group AND the World group can view it.

If the read and write permissions for ‘ABC Company’ are set to Europe, this means that users in both the Austria group AND the Europe group can view it. Users in the World group cannot view it.

If the read and write permissions for ‘ABC Company’ are set to Austria, this means that only users in the Austria group can view it. Users in the World and Europe groups cannot view it.