Trying to understand Revolution Permissions...

I’m working on a Revo site (finally moved over from Evo) and trying to get my head around Revo’s Permissions setup. I’ve read the docs by Bob Ray which is very thorough (thanks Bob for taking the time to write this: http://bobsguides.com/revolution-permissions.html), but has anyone seen or come across documentation that explains the permission’s setup in a way that’s a little more simplified giving a little more of an overview? I think my head split after trying to get through Bob’s docs as it seems extremely complicated. I guess I’m struggling trying to see the forest from the leaves ... my biggest challenge is trying to understand how everything ties together ... the big picture. I see the potential in the ability to be very granular in setting the permissions up, but I’m a bit lost.

Does anyone have any specific use-case explains they can explain? I think if I could see this in action, I’d be more than glad once I get my head around it to put a video together to try to explain it which will hopefully help others.

There are some specific tutorials here that you might have missed: http://bobsguides.com/revo-security-tutorials.html.

The "Advanced" section items might serve as specific use-case scenarios (or not).

If you can describe something you’re trying to accomplish, we might be able to point you in the right direction. I think it’s easier to understand the permissions system if you have some specific goal in mind.

Hey Bob,

Thanks for the response...much appreciated. I’ll go through these tuts and respond back here afterwards. Again, I think my biggest struggle is trying to figure out how the permissions system all ties together. I just don’t see the flow off the top of my head. I was able to get a new Manager setup, but to be honest I can’t quite figure out a day later how I did it A more overview perspective would help me in understanding how all the settings tie together.

Lets try a cheatsheet approach.

Basic Permission Stuff
-------------------

Permission - Permission to perform a specific action (e.g. save something, see the resource tree, see the element tree, upload a file, etc.).

Access Policy - Just a list of Permissions that are checked or unchecked. When a Permission rule attaches a Policy to a User Group, the users get the checked Permissions.

Access Policy Template -- A list of Permissions that will show up in a Policy based on that template. In the Policy, the user gets the checked Permissions, but there’s no way to give them Permissions that aren’t in the Policy Template because they won’t show in the Policy.

User Group - A list of users. All Permissions, at this point, are granted to User Groups. No Permissions are tied to individual users. If you want to give and deny specific Permissions for a user, you have to put the user in a User Group. User Groups can be connected to policies (to control the users’ Permissions) and to Resource Groups (to control access to resources).

Resource Group -- A list of resources (e.g., documents). Controlling which resources a user can see (i.e. hiding resources), and what the users can do with those specific resources (e.g., save them, edit them, view them), is done through Resource Groups. At this point, there are no Permission controls for individual resources, only for Resource Groups.

Role - A specified authority level with an arbitrary name. Every Role has an Authority Number that determines how powerful users with that Role are. The lower the number, the greater the power. Roles in Revolution don’t have Permissions attached to them like they do in Evolution. The only really important thing about Roles is the Authority Number. Each Role has a single Authority Number. Make sure that the more powerful the user, the lower the Authority Number of his or her Role. When a Policy is attached to a User Group in a Permission rule, users with the Minimum Role (or roles with an equal or lower number) get the checked Permissions in the Policy. Also (again, unlike Evolution), users can have different Roles in different User Groups, though they don’t need to.

Minimum Role -- The Minimum Role (based on authority number) that qualifies users to get the checked Permissions in a Policy. When a Permission rule attaches a Policy to a User Group, the Minimum Role determines which users get the checked Permissions in the Policy. Users that meet the Minimum Role (by having a Role in the group with an authority number equal or lower than the specified Minimum Role get the checked Permissions in the Policy. Others don’t.

Context Access permission rules (AKA Context Access ACL entries) connect Contexts (e.g., ’web’ and ’mgr’) to User Groups. Which Permissions are checked in the specified Policy will determine what the users in the User Group can do, in general, in that Context (e.g., view resources, save resources, edit snippets, create plugins, etc.). The connection also hides the Context from other users.

Resource Group Access permission rules (AKA Resource Group Access ACL entries) connect User Groups to Resource Groups. Which Permissions are checked in the specified Policy will determine what users in the User Group can do with the resources in the Resource Group. The connection also hides the resources in the Resource Group from other users.

Element Category Access permission rules (AKA Element Category Access ACL entries) connect User Groups to groups of elements (chunks, snippets, templates, TVs, and plugins) in a particular Category. They work exactly like Resource Group Access permission rules, except that they work with elements rather than resources and the element group is a Category rather than a Resource Group.

Inheritance of Permissions - Users in a User Group with a particular Role will get the checked Permissions on the Policy with that Minimum Role specified in any ACL entry for that group. Because of inheritance, however, they’ll also get the checked Permissions from other ACL entries with a Minimum Role that has an equal or higher authority number. This only operates within the User Group. Users will never get Permissions given to another User Group, no matter what Minimum Roles are specified in the other group.

Context -- A particular part of MODX. The default Contexts are the ’mgr’ Context and the ’web’ Context. The ’mgr’ Context is the MODX Manager. To log in to the Manager, you need to belong to a User Group that has a Context Access ACL entry with a context of ’mgr’. The ’web’ Context is essentially the front end, with the exception that in order to see resources under the ’web’ icon in the Manager’s Resource tree, you need to belong to a User Group that has a Context Access ACL entry with a Context of ’web’. Other Contexts can be created and they all work just like the ’web’ Context.

Protection -- Hiding stuff. If something is unprotected, anyone can see it. Contexts are protected when a Context Access ACL entry connects a User Group to a Context. The ’mgr’ Context is protected by default because a Context Access ACL entry connects it to the Administrator User Group. As a result, no one can log in to the Manager unless a) they are added to the Administrator user group, or b) They belong to another User Group that has a Context Access ACL entry with a Context of ’mgr’. The ’web’ Context is also protected by default in the Manager because there is a Context Access ACL entry connecting it to the Administrator user group. No one can see the resources in the ’web’ context in the Resource tree of the Manager unless a) they belong to the Administrator user group or b) they belong to another user group with a Context Access ACL entry with a Context of ’web’.

Resources are protected when they belong to a Resource Group that is connected to a User Group with a Resource Group Access ACL entry. To see those resources, you need to a) belong to that User Group or b) belong to another User Group that has a Resource Group Access ACL entry for that Resource Group. Because there are no default Resource Group Access ACL entries, all resources are unprotected in both the Manager and the front end unless you create Resource Group Access ACL entries that protect them.

Elements are protected when they belong to a Category that is connected to a User Group with an Element Category Access ACL entry. To see those elements, you need to a) belong to that User Group or b) belong to another User Group that has an Element Category Access ACL entry for that Category. Because there are no default Element Category Access ACL entries, all elements are unprotected by default.

ACL entries like the ones described above only protect things in the Context specified in the ACL entry. IOW, an ACL entry with a Context of ’mgr’ connecting a Resource group to a User Group will protect those resources in the Manager, but the resources will remain unprotected in the front end (’web’ Context) unless there is another ACL entry for them with a Context of ’web’.

Note: I generally recommend that you *don’t* add users to the Administrator User Group unless they will be very high-level administrators on the site. In other cases, putting them in separate User Groups will give you greater flexibility when designing Form Customization rules, because Form Customization rules can be tied to specific User Groups, but not to specific Roles.

Form Customization
-----------------

At present, Form Customization only applies to the Create/Edit Resource panel and its various tabs. You can do some security stuff by hiding fields or tabs of the panel from everyone, or from users in specific user groups. You can also customize the panel by moving things to different tabs, by creating new tabs, and by setting captions and default values for specific fields on the panel. You can have different rules (or the same rules) for creating new resources and for editing existing resources.





Also -- Did you see this nice visual representation of giving User Groups access to specific resources? http://lithiumlab.com/modx/revo_permissions.html