Revo most complicated permissions system

EVER!

I dont remember seeing such complicated user permissions system anywhere...

So, could someone please point me in the right direction to the most compact/clearest permissions explanation they’ve come accross please?

I am liking MODx but this is something else.... heeelp.
Referring to Revolution here... using 2.0.8pl if that makes any difference.

thank you so much!

http://bobsguides.com/revolution-permissions.html

I’ll assume you’ve read the fine manual, and watched the vid at http://rtfm.modx.com/display/revolution20/Permissions

I found the cheatsheat on permissions here to be helpful - it has diagrams and a military analogy, that help you visualise it:
http://modxcms.com/forums/index.php/topic,48252.0.html

Quote from: crunch at Mar 17, 2011, 11:43 PM

I’ll assume you’ve read the fine manual, and watched the vid at http://rtfm.modx.com/display/revolution20/Permissions

I found the cheatsheat on permissions here to be helpful - it has diagrams and a military analogy, that help you visualise it:
http://modxcms.com/forums/index.php/topic,48252.0.html

Thanks for these. They are very confusing though. I shall write my own guide once I get the concept. I am not sure why it has to be so complicated. Compared to other systems i’ve used in the past this is just crazy.

its so complicated because it so flexible.

I just created a new user in Revolution for the first time and MAN what A Gong Show! Seriously, without this guide i don’t think i’d have figured it out:

http://rtfm.modx.com/display/revolution20/Giving+a+User+Manager+Access

Note: favorite part no question is that after you’ve created a new user, a new role and an new access policy you then have then go back to User Groups right click on NOT THE USER but the User Group and select "Update User Group" so you can then add TWO new ACL entries for both mgr AND web contexts to finally assign desired permissions to the new user.

Seriously, I’m not making this up.

It’s insane.

Most of the time you would define your Roles (you don’t need these in most cases, being a Member of a group is enough unless you need different permissions within a group based on their "role" in it), Policies, User Groups, and their Access Control Lists for Contexts, Resource Groups, and/or Element Categories up front. You then simply add Users to the appropriate User Group( s ). If you have suggestions for improving the usability of the system, sharing that would be appreciated.

Here’s what I think could be very user friendly:

Leave the ACLs and their templates/management for advanced users as an optional system to use. Have ACLs pre-assigned and editable directly from the user groups "permissions" tab. that way you could have the ACL menu turned off completely and if needed it could be turned on for advanced users to be able to save preconfigured lists, apply them to groups, merge them etc.

User groups could be hierarchical, having subgroups, where subgroup automatically inherits the parent groups permissions. Have them all in a nice tree. (basically renaming "roles" to subgroups and having an option to assign a user to several subgroups.)

Each group/subgroup could have a few tabs - [1. users] [2. permissions]

1. users tab - self explanatory. add/remove users
2. permissions tab - have a single place to manage partical group’s access to anything. It would basically could be visually structured in some accordion menu or tree form again or using a grid, where you can filter all the actions the users are permitted to do in every which way (by context, by category, by keyword etc.)
optionally (ACL management feature that can be turned on/off) then these permissions could be saved as reusable sets (ACLs) or saved ones could be applied (overwriting or merging)

would this be too limiting? I think not. But at least then you have generally only 2 places to go to when you need to change basic settings as opposed to 8-10 different tabs on 2-3 different menus.

Users
same with the users. a user editing menu could have perhaps 2 tabs as well.. [1. groups] (and subgroups it belongs to) [2. permissions]

1. groups - again, nice tree view with checkboxes for each
2. permissions - show the full list of effective site wide permissions. the ones inherited by a group membership could be greyed out, but overridable (change colour) as well as completely individual permissions could be set (again, different colour)

I guess, in the background of all this ACLs and policies could essentially drive it all, just the way of managing it should really be much more friendly.

Also it would be fantastic if we were able to right-click on any element/resource/file in the tree and check its effective permissions (e.g. groups/users who have access and what permissions)

What do you think? perhaps a diagram/wireframe would be helpful to illustrate this idea?

Could be a lot of work to implement, but maybe i’m wrong...

We are all eager to make the UI/UX more intuitive, but re-architecting the core system is not really necessary IMO. The attribute-based access control system we have chosen to implement is very solid, flexible, and extensible. There just needs to be a better way to manage it as you said; we can all agree on that.

Quote from: krisj at Apr 18, 2011, 12:27 PM

Leave the ACLs and their templates/management for advanced users as an optional system to use. Have ACLs pre-assigned and editable directly from the user groups "permissions" tab. that way you could have the ACL menu turned off completely and if needed it could be turned on for advanced users to be able to save preconfigured lists, apply them to groups, merge them etc.

The original intention was for common security scenarios to be packaged as Extras that can be downloaded and installed via Package Management. These "Access Control Templates" would have a set of pre-designed User Groups, Policies, and ACLs to be used as starting points for non-advanced users and eventually could be packaged together with other Extras to make custom distributions of MODX Revolution targeted at specific requirements.

Quote from: krisj at Apr 18, 2011, 12:27 PM

User groups could be hierarchical, having subgroups, where subgroup automatically inherits the parent groups permissions. Have them all in a nice tree. (basically renaming "roles" to subgroups and having an option to assign a user to several subgroups.)

User Groups are already hierarchical, and inheritance for User Groups is on the roadmap, though it will not replace Roles. Roles describe a User’s Role within a specific Group, and there are use cases for having both a hierarchical User Group structure in addition to delineating Roles within each Group.

Quote from: krisj at Apr 18, 2011, 12:27 PM

2. permissions tab - have a single place to manage partical group’s access to anything. It would basically could be visually structured in some accordion menu or tree form again or using a grid, where you can filter all the actions the users are permitted to do in every which way (by context, by category, by keyword etc.)

The idea behind having policies is to abstract the management of specific permissions. This is delegated to the Policy design stage. IOW, you predefine and name your Policies in a way that makes management of permissions per User Group much more intuitive than scanning a list of potentially hundreds of individual permissions.

Quote from: krisj at Apr 18, 2011, 12:27 PM

Users
same with the users. a user editing menu could have perhaps 2 tabs as well.. [1. groups] (and subgroups it belongs to) [2. permissions]

1. groups - again, nice tree view with checkboxes for each
2. permissions - show the full list of effective site wide permissions. the ones inherited by a group membership could be greyed out, but overridable (change colour) as well as completely individual permissions could be set (again, different colour)

Having a read only view of a User’s (or User Group’s) effective permissions based on the assigned Policies sounds like a great feature request actually. This could not be used to manage User "permissions", though in the future Policies will be able to be tied to individual Users directly, so we will also need a way to manage those on the Users (as we do now on the User Groups).

what about the following:

add the ability to filter Access Policies by sub group (similar to System Settings)
or something so it doesn’t feel like reading the fine print on a tax when navigating the 130+ access policies.

and add the ability to assign ACL’s directly to a user.
either overriding the built in user permissions system, or like quick/automatic setup.

would be great for those few times when you’re not setting up site with 100’s of users