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.