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.
- 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