New Revo Permissions GUI - wireframe suggestion#

As I have been trying to figure somethings out via ACLs/Permissions I think I have a better understanding on how they work and I wish to provide a GUI suggestion to simplify this process.

Attached you will see my wireframe mockups. modx-revo-Basic-Permissions.png this wireframe would replace both the Users and Content Access tabs for Security->Access Controls->New User Group/Update User Group. All text in red is just to explain what should happen on the page. I may post a Resource Group Access wireframe later if I have time to develop it.

Note I used Pencil to create these mockups: http://pencil.evolus.vn/en-US/Home.aspx and if anyone wants it I will send you the working file.

Thanks for reading and hopefully this is helpful.

I like those ideas very much.

If there are good returns, i may try to put a working extjs mockup to propose to the modx team.

Thanks for the idea! However, this won't work, for a few reasons:

1. Scalability - the Users should be on a separate tab in a grid, since you need to have the ability to scale to 10,000+ users in a group.
2. The Context Access portion of your UI only allows for *one* Access Policy to be applied to each Context. However, MODX allows for multiple Policies per Context (in fact, usually requires it).
3. Selecting the Role up top won't really work, as Roles can have their Policies inherited (hence, Minimum Role). So the Users checkboxes below that would be incorrectly matched with the Permissions, since Permissions/Policies can be inherited by Roles with greater authorities.

Thanks for the feedback, I modified my design based on your comments and explained things a little better.
My response to your points

[list]
• 1. User and roles have a 1 to 1 relationship with in the context of a group. Therefore my thought is that it is easier for a newbie(and me) to connect how roles/users/permissions(at least to context) work. This might still need work for those 10,000 user sites.
  
• 2. In response to your comments I changed my thoughts on how loading the Access Polices would work:
  Every time you select an Access Policy and then click load it will only check the checkboxes of the permissions in its policy and it would not uncheck others therefore it would allow multiple Access Policies. The Clear button would remove all checks from the permissions fields and the All Permissions would select everything for you.
  
• 3. Currently (if I understand correctly) every Context Access entry has only one Role assigned to it and only one Access Policy assigned to it per entry. Both in the GUI and in the DB. Inherited permissions would be set to readonly and marked visually to indicate that they are inherited. Once you hover over them it would tell you what role has that permission.

[/list]

Technical – how to development it in the DB.
I would say keep the current structure on how everything works but just add a little to it.

Option 1: Add a new DB table – access_permission_defaults, with columns id, name, description, perm_type (like View, Add, Edit&hellip, namespace (core or some extra) – then you could sort them in the table that is in the sketch.
Option 2: Add the perm_type and namespace columns to the existing access_permissions table. Then assign then to a Access Policy like All Perms.

Now the way I understand the DB every permission has to be tied to an Access Policy and that would get messy if you made a lot of little changes and each Role basically created an Access Policy. So I would suggest adding another column to the access_policies table something like visible with 1/0 values. All of these “created” Access Policies would be set to 0 and not show up in the GUI to select. This still allows those that wish to create custom Access Policy groups but the person that does not really understand how Access Policies relate to be able to see all of it on one page.

Where did those screenshots go? I'd like to have a look a this... I was considering sketching up my own graph for this simply as a visual to help users understand how all the pieces work.