The title of this article should really be "Why Severely Limit Membership in the Administrator User Group," but it was too long already. The Administrator group, in my opinion, should have very few members. In this article I’ll discuss why I think that’s a good idea.
Why Not Have Lots of Administrators?
You might be tempted to put all your Manager users in the Administrator group. It simplifies things somewhat, since you only need one set of Context Access ACL entries. The trouble is that unless you mess with their Roles, they’ll all have the same capabilities. If you’ve seen my video on MODX Revolution Security Permissions, you know that I don’t recommend using Roles to control what users can see and do in the Manager. The permission system is complicated enough without adding Roles as a variable. Doing so can lead to confusion and difficulty when trying to fine-tune and test your permission system, especially since users with higher-authority Roles (lower authority numbers) inherit the permissions of all users in the same group with lower levels. If I need users with different capabilities, I generally put them in separate User Groups.
Consider the access_permissions permission. If a user has that, they can change anyone’s access level (including yours). They can make themselves sudo users and bypass all permission settings, and they can lock you out of your own Manager at will. If you have that permission and don’t use Roles, all the other Administrator users will have it too. Suppose that you do use Roles, and specify which Administrator users have that permission by setting authority levels. If you create a new Administrator user and accidentally give them the wrong authority level, they’ll have that permission. To get it right, you’d probably have to review your authority levels. That could get pretty time-consuming because you might also have to go look at the various Access Policies associated with each authority number. It’s much simpler to create a User Group with a meaningful name that gives all its users the same rights.
I will generally put only users who need full access to the Manager in the Administrator group. Often, that’s just me (as the developer). Sometimes a client will insist on full access, but if you don’t tell them they don’t have full access, and they can do everything they need to do, they generally won’t be aware that there are parts of the Manager they can’t see.
Greater Flexibility
The best reason for creating separate groups for your Manager users is that it much easier to fine-tune permissions. You may not need it at first, but it’s very likely to crop up at some point. After a site has been up for a while, you, or your client may decide that the content editors shouldn’t be able to delete Resources. If the content editors are in a separate User Group, all you have to do is edit the Context Access Policy for their group and uncheck the delete_document permission. That’s much easier than trying to either mess with their Roles in the Administrator group and the attached Policies or move them all to another User Group and create a new Policy for it.
Having the users in separate groups also gives you much more flexibility with Form Customization rules. The FC rules can be applied to a specific User Group, but not to users with different Roles.
Hiding Things
Sometimes, you may want to hide things in the Manager with CSS and a snippet, or plugin. It’s a lot easier to have the code apply to specific User Groups than to try to adjust it on the basis of User Roles (especially since users can have different Roles in different User Groups). If users who need a specific set of capabilities are all in a separate User Group, it’s much simpler to put code in the snippet or plugin that just applies to their User Group:
if ($modx->user->isMember('GroupName') {
/* Group-specific code here */
}
YMMV
The decision to put many users in the Administrator User Group is a matter of personal taste, and as with so many things in MODX, you’re free to do it any way you like. My experience, though, is that it will lead to headaches down the road.
I would still generally use my approach on a large and complex site, but at some level of complexity, you might find it necessary to use Roles rather than having a multitude of user groups. Needless to say, it would be best to make this decision as early as possible, since switching strategies could be very time-consuming.
Mea Culpa
In earlier articles and in my Vimeo speech, I gave some bad advice about what Roles to assign. Since my strategy of putting users in different groups rather than assigning different Roles means that the role authority levels are meaningless, I recommended giving all users the same role authority level (I suggested the arbitrary authority level of 15). In the current version of MODX, this is no longer possible as Setup will crash if the values are not unique. According to OpenGeek, this was always intended, but never enforced. The problem is a result of this change: "Make authority a unique index on modUserGroupRole (#16587)." When you try to save a new Role with an authority level that is not unique, you are unable to save the Role.
At this writing, the error message from Setup is: "Multiple modUserGroup records with the same authority were found." This is somewhat misleading, because it’s not a problem with the modUserGroup, it’s a problem with the modUserGroupRole object.
You can either make all the authority levels different, or as another possibility suggested by OpenGeek, make the authority levels all 9999, which should not crash Setup. If you use my strategy of separating users by User Group rather than Role, the roles are meaningless, so using 9999 is probably the easier fix.
Bob Ray is the author of the MODX: The Official Guide and dozens of MODX Extras including QuickEmail, NewsPublisher, SiteCheck, GoRevo, Personalize, EZfaq, MyComponent and many more. His website is Bob’s Guides. It not only includes a plethora of MODX tutorials but there are some really great bread recipes there, as well.