Working with Access Policies is confusing for a number of reasons. Access Policies are based on Policy Templates, which in turn are based on five Template Groups. They are Admin, Resource, Element, Object and Media Source. When setting User Group Access Policies, selectable Policies are restricted to those based on Admin + Object (Context Access), Resource + Object (Resource Group Access), Element + Object (Element Category Access) and Media Source (Media Sources Access) Template Groups. How these Policies interact is somewhat of a mystery. Admin Policies contain a lot of Permissions that refer to working with Resources, Elements, Objects and Media Sources. Object Policies only contain generic Permissions which will make them inevitably overlap with any specific Policy. So what happens when Policies conflict? What hierarchy is applied?
Trying to unravel the mysteries of the ACL system, I'm beginning to understand why I and so many others are struggling to get a grip. Why doesn't MODX use the basic separation of Admin, Resource, Element, Object and Media Source as a guideline for everything that happens with security? And use it in a consistent and transparent way? It would reduce conflicts and allow for tying Policies to MODX elements in a more logical way.
Reorganising Permissions and Policies
First, the separation between Admin, Resource, Element, Object and Media Source should be consistent on the most profound level.
1. The Manager Context (mgr) should be treated as a distinct entity, separate from any other Context. This will allow us to separate Permissions applying to the Manager from those applying to something else.
2. Permissions in the Admin Template Group that apply to anything else but access to the Manager or any of the Top Menu items should be moved to another, appropriate Template Group.
Once this is done, the separation needs to be reflected in the UI by reorganising the Access tabs in the User Group settings.
3. Add a Manager Access tab. This will contain the Admin Policies. These will only apply to the Manager Context and not to any of the other Contexts.
4. On each Access tab there should be a single mandatory Generic Policy and any number of Specific Policies. Specific Policies will always overrule Generic Policies in case of a conflict. This should clarify the hierarchy between Policies.
5. When setting a Specific Policy, it should be possible to make it apply to 'Any Context', meaning any Context visible in the Resource Tree, not the Manager. This should prevent an excessive amount of Policies in a setup using many Contexts. (It might even be preferable to have Access rules applying to a specific Context, overrule conflicting rules applying to All Contexts.)
Now we can further organise and streamline the UI to support the above changes.
6. Policy Templates are based on Template Groups. Currently all preset Policy Templates have all available Permissions activated. That more or less implies Policy Templates are obsolete. Let's say we remove them and base Access Policies on Template Groups instead.
7. To simplify creating Access Policies we need to group the lists of Permissions. The
jsfiddle document of
crunch is a good example of how this could be done.
8. To make Permissions sort in a logical and consistent way and make them more readable, they should be given a title reflecting their action and the element they apply to.
9a. Some Permissions are obsolete. For instance: what use is it to restrict a User from logging out?
9b. Some Permissions are redundant. For instance: what does a Permission like 'Save' add on top of 'Edit'? I know sometimes it's possible to edit settings without saving them, but the basic principle is the same: you adjust a setting. Distinguishing between the two merely adds confusion, not more control.
9c. Some Permissions could (or should) be added. In the
jsfiddle document of crunch there's some suggestions.
Some additional thoughts
I've suggested to include a mandatory Generic Policy for each Acces tab in the User Group settings. This assumes Object Permissions and generic Permissions specific to the Manager, Resources, Elements or Media Sources could be combined to form a single Policy. This may not be the case, I'm not sure how they relate to each other. Essential is that you could set a single, simple rule to cover all (unexpected) situations and divert from that rule with more specific ones.
When setting User Group options, it may be possible and desirable to combine the Context Acces tab with the Resource Group Access tabs. In fact, I sometimes wonder if it would make sense to restrict access to Contexts using Resource Groups, but that might lead to technical or logical problems.
Finally I'd like to say that everytime I try to bend my head around this problem, I get more convinced that a separation between the Manager and the other Contexts (at least in the UI) is essential to setting things straight.
☆ A M B ☆
☆ A M B ☆
