Enhancement - MODX Permissions

[tomireland]

MODX Permissions

Summary:

I had some ideas/suggestions for potential, future improvements.

There are probably many contributors that have submitted their own views, or you may have your own, however this is just my general thoughts.

As with many MODX users, I find MODX permissions quite complex to setup and even more complicated when trying to explain them to end-users e.g. non-technical clients etc.

Through my day job, I am an administrator for a number of SharePoint sites and I think some of the permission principles could be applied to MODX. SharePoint has it's own set of issues (not being friendly for templating is one), but it does permissions pretty well.

I'm going to assume that you don't know anything about SharePoint in this instance.

How SharePoint permissions work

Thinking purely about SharePoint sites (excluding Site Collections), permissions are applied at 3 levels:

• Site level (Globally across the whole site)
• Library level (On specific collections of items that are contained in libraries e.g. Document Library, Image Library etc.)
• Item level (Items within libraries)

MODX, thinking about it, seems to operate in a similar way to SharePoint, except there are no roles in SharePoint and there is only one context, as SharePoint site administration is done in the front-end anyway.

The way SharePoint works is:

1. You setup user groups e.g. Admins, Members etc at site/system level (these are global)

There are some group specific settings that you can apply, for example; who can edit the group e.g. named system admin or a specific group

1. You assign a single permissions policy to the appropriate groups e.g. Full Control, Contributor, View Only etc.

See this SharePoint permissions list as an example. It is similar to the way MODX defines policy permissions looking at it, except there are fewer. I don't think this would be a detriment to MODX in anyway if the list was simplified or multiple detailed permissions were possibly rolled into one that was more simplified.

1. You add users to the appropriate groups, providing they are on the system already
2. All libraries (collections of items) and items inherit the top-level site permissions i.e. groups of users inherit the same permissions that have been applied to the group they're in, for everything across the site
3. For specific libraries or items, you can choose to not inherit permissions and set unique permissions to enable tighter control over things at a lower level

In SharePoint, permission policies are set out-of-the-box, although you can create custom one's from an existing template (similar to MODX), except the permissions in SharePoint are not as many or as granular, but they give you flexible control.

In relation to MODX

As mentioned, I think that MODX permissions work in a similar way to SharePoint permissions, except I find MODX permissions really confusing for some reason.

User Groups
These are good and makes sense to me, although there's a consistent thing with applying roles in the tabs that confuses me.

Policy Templates
The way that policy templates are currently listed could be improved by showing a list of the same permissions for each template, but depending on the template, certain permissions would be greyed out.

You might say that there's not any point having certain permissions listed if they're not usable, but all templates would have a consistent, recognisable list of permissions and this would make it a better experience for the user to instantly understand what's possible and what's not for a given policy template

Roles
Would it be possible to do away with Roles? Not sure. I don't fully understand how they work, but would they be needed if MODX were to adopt a simpler approach as mentioned above?

Resource Groups
Again, don't really get them and had to play around for a while to get some stuff to work properly when I was doing it.

My immediate thought would be that resources would inherit permissions linked to certain groups and those groups would be displayed in the access settings of the resource. The admin would then have an option to remove specific groups from a specific resource or modify the permissions for that group slightly, within the resource, if they chose to.

I'll shut up now...

I'm not a seasoned developer by any stretch of the imagination and I totally understand that my objective view sounds simpler than it probably would be to implement or change.

However, it's something to think about.