I’ve been working on issue #14929, which has revealed the need for a bit more than fixing the visibility of the context menu trigger (gear icon) in the grids. I’ve run across a bunch of scenarios where visibility of buttons, options, menus does not line up with a user with limited permissions. As I work to solve the issues I’ve found, there are a few things I’d like to understand better, including some suggestions:
Object-level permissions (those that further affect group permissions, e.g., media source, namespace, context, etc.): From what I’ve gathered, these are subtractive only; for example, if group permissions to edit a media source are set to false, you cannot then grant edit access at the object level by applying the Media Source Admin policy on that source. However, the opposite is true — you can further limit access on the object level. I just wanted to verify whether I understand this correctly.
There are a handful of built-in settings/policies/contexts/etc that I believe should be protected from deletion (e.g., the mgr and web contexts, the Filesystem source, all of the pre-installed policies and policy templates, content types, etc.). My question on this front is two-fold:
I think most, if not all, of these built-in properties should be completely locked down (no editing as well) and the names and descriptions directly drawn from lexicons. Is that the current intention? If not, what do you all think? Assuming this is the right idea, the next-level editing forms could have display fields instead of actual form fields for built-ins. User-created objects would continue to have full editability for those with appropriate permissions.
Would it be desirable to group these properties in the grid (“built-in” or “modx” for stock properties, “user” for user properties)? This could be helpful with the longer property lists (policies and policy templates) if a user creates a bunch of their own. This could be done in the code without touching the database.
In the generated javascript, a grid row’s record contains both a data property and a json property, both of which are virtually identical in both content and format. Does anyone know why these are separated out?
Some grids that are not particularly large content-wise (media sources, policies, and policy templates) use the checkbox selection model. Could we consider not using this model for those? One of the trickier things to solve with this model is how to change it on the fly when there are no actionable menu items in the batch menu; when a user does not have delete permission, there’s nothing that can be done by selecting via the checkboxes, as we offer only batch delete in most of the grids (in which case we should not be showing the checkboxes at all).
Anyway, I’m not trying to hit all these items at once in the process of working on the referenced issue … just want to be sure my decisions on it will be as informed as possible
You might be interested in this ~50-minute video on how the MODX permissions system works.
#1 - As far as I know, if a user is granted a permission to do something, it can’t be taken away by another permission setting. The only exception would be that Administrative permissions have priority over object permissions. For example, if a user doesn’t have permission in an Administrator policy to edit resources, no resource group access policy will let them do so. On a larger scale, if the user doesn’t have permission to access the mgr context, no object permission will let them do anything in the manager.
#2 - There’s a conflict here between preventing the user from doing something stupid, and the MODX ideal of total freedom. Any decision on this topic would be a compromise. That said, a user can always duplicate a policy or policy template and use that instead of the original., so I would support locking and protecting the built-in policies and policy templates, but I’m not sure about settings and contexts. With settings, remember that anyone with the authority can create user settings, usergroup settings, and context settings that will override the corresponding System Settings.
#1 - OK, so for the most part you’re verifying what I’m finding. Although you can place additional limitations on the objects found within a user group’s Access Permissions (on contexts, resource groups, media sources, elements, and namespaces). For example, a user group member may have permissions to edit, say, media sources in general — but may be limited to viewing/loading only on specific sources by applying the Media Source User policy to them.
#2 - I probably should not have included “settings” in that question … I was thinking more in general (maybe built-in configuration properties would be a better catch-all term?). That said, there are a handful of system settings that would break a site if one were to delete them. Anyway, to me, I’d say total freedom to create is what you’d strive for, not to destroy
#4 - It’s the Ext model that generates the checkboxes used in many of the grids (for the batch edit functionality). The batch functionality in most areas (aside from Resources) just has the option to delete. That’s where I’m more focused as far as this question goes. Just thinking you’re not likely to need/want to batch delete items in many of these areas (contexts, sources, policies).
OK, for anyone interested, I did figure out #3:
The data property of the record object is created internally by Ext based on the fields specified in the grid’s config. It derives its values from those with corresponding keys in the json property, which holds results from Ext’s JsonReader (or ArrayReader), which in turn gets its data from the modx’s GetList processor. The fields can be mixed, both those that save values to the database or arbitrary ones.
