Here's two jsfiddle documents showing what I tried to say in my previous post. (With a big thank you to
crunch for making the
original jsfiddle document.)
Access Policy Template Groups (
view jsfiddle)
Each tab represents a Template Group. The originals can be viewed when editing Policy Templates (Security > Access Controls > Policy Templates).
The current security system is very convoluted and hard to understand. In an attempt to unravel the chaos the following decisions have been made:
1. Template Groups would be used to base Access Policies on. Policy Templates could be removed.
2. The Admin Group has been split up into an Admin, Resource, Element and File & Folder Group. The original (largely overlapping) Resource, Element, Media Source and Object Groups have been merged into a single Object Group.
3. The Permissions have been given consistent names and were then grouped and sorted.
4. Since the MODX security system needs to be understood by laymen (most notably clients), all Save Permissions have been left out to be replaced by Edit Permissions. For the same reason all Load and List Permissions have been removed in favour of View Permissions.
5. A number of Permissions have been moved to the User group Access tabs. Amongst them the Permissions to access the Manager, the Resources tab, the Elements tab and the Files tab.
User Group Access Tabs (
view jsfiddle)
Each tab represents an Access tab. The originals can be viewed when updating a User Group (Security > Access Controls > User Groups > Update).
It makes sense to try and match the way Template Groups are split up when creating Access Rules.
1. The Manager Access tab contains Rules specific for Manager Access and using the Top Menu.
2. The Resource Access tab contains Rules for access to the Resources tab, and for using Contexts and Resources. It also contains Rules for Resource Groups.
3. The Elements Access tab contains Rules for access to the Elements tab, and for using Elements and Property Sets. It also contains Rules for Element Categories.
4. The Files Access tab contains Rules for access to the Files tab, and for using files and directories. It also contains Rules for Media Sources.
5. Note that it's usually possible to select 'No Access' or 'All ...' (i.e. 'All Contexts').
These suggested changes leave the underlying structure of the current security system mostly intact. There are still Users, User Groups, Roles, Resource Groups and Access Policies. And after all Access Rules have been set, it should result in a security setup which is not much different from what you would get with Revo 2.2. The main differences are in (the organization of) the interface. There's some adjustments that may seem drastic, but what happens in the interface, doesn't necessarily need to happen in the code.
The whole system could probably be made even simpler, by using Authorization Levels and inheritance, as suggested by
Mark Hamstra and
BobRay.
Having said that...
Two things that would make Roles easier to understand and use
1. I agree with
BobRay, that it would be much less confusing if Authorization Levels would be inverted. A high number should reflect a high Level, rather than the other way around. The current approach is prone to mistakes. For instance you could give Super Users a Level of 99 and Members a Level of 0.
2. Currently Roles need to be given very generic names, since they show up in every User Group. Which in itself is a problem, since not all User Groups require the same number of Roles. That means you never know what Roles are in use, and exactly what user base each Role represents. User Group specific Roles should eliminate these problems, since all names will be self explanatory and only those Roles that can be used will be shown.