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 leads to a lot of 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. My recommendation is that if you need users with different capabilities, you should put them in a separate User Group.
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 control 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 look up which authority levels give which permissions, which could be pretty time-consuming because you might 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 may not 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 gives you much greater flexibility in fine-tuning 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, the 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
In some upcoming articles, we'll look at ways to hide things in the Manager with CSS and a plugin. It's a lot easier to have the plugin 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 plugin that just applies to their User Group.
YMMV
The decision to put many users in the Administrator User Group is a matter or 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.
Coming Up
For more information on how to use MODX to create a web site, see my web site Bob's Guides, or better yet, buy my book: MODX: The Official Guide.
Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at Hosting.com (formerly A2 Hosting). (More information in the box below.)
Comments (0)
Please login to comment.