make ACLs easier or provide wizard

I've already been working on more concrete stuff and I'll be sure to share it as soon as I'm happy with it. I'll be away for a couple days though, so it will have to wait until next week.

So far I've been trying to organize and categorize all the security settings to get a better view. I've noticed that there's a lot of little inconsistencies and seemingly obsolete settings (Restricting access to the Help pages?! Disallowing the user to logout?!), so I guess a good clean-up would be my first suggestion ; )

More useful stuff (or stuff of more use) next time.

What is the Template Group? Why can't we edit it?
What is the purpose of it? [ed. note: goldsky last edited this post 12 years, 3 months ago.]

Here attached is the default modx 2.2.0-pl2 permissions table.
Hm... this can make me mad.

How do you guys map the relation among these templates?

There is a Developer policy. What's this?
It has exactly the same permissions with Administrator.

Why do you distinct the ElementTemplate and ObjectTemplate?
They have the same basic permissions. [ed. note: goldsky last edited this post 12 years, 3 months ago.]

Quote from: goldsky at Jan 21, 2012, 02:05 AM

What is the Template Group? Why can't we edit it?
What is the purpose of it?

Right click it in the grid and choose update. Click the button to add new permissions, right click a row in the grid to remove. The reason you shouldn't edit the core ones is that they will be updated/restored when you update MODX in order to add any new permissions that may have been added in a new version.

The purpose of a policy template is to offer a collection of related permissions - either related to administrative tasks and viewing parts of the manager or specific areas such as elements and media sources. Just like a regular template it gives you the basics - your access policies use the templates to decide which of those permissions are actually granted.

Quote from: goldsky at Jan 21, 2012, 02:13 AM

Here attached is the default modx 2.2.0-pl2 permissions table.
Hm... this can make me mad.

How do you guys map the relation among these templates?

The different templates in that sheet (resource, object, element and media source) are, and that's the whole point, not related. Their permissions may share their name (eg "create" and "save"), but they apply to different things or actions.

If you save a template, your permissions will be checked for the Element->Save permission. If you save a resource it'll check Resource->Save.

There is a Developer policy. What's this?
It has exactly the same permissions with Administrator.

Doesn't seem to be in my copies of 2.2 - perhaps you duplicated the admin one or it's been a recent add missing in my installs. If it's the same, it does the same..

Why do you distinct the ElementTemplate and ObjectTemplate?
They have the same basic permissions.

There's more types of objects other than elements.. virtually every piece of data is an object (system settings, menu items, custom tables,...) - while I haven't worked with the object ones I'm going to guess element only applies to elements, and objects to the rest (outside of resources/media sources)

I'm going to oppose forcing a resource group with a user group. While it makes sense in some use cases (sections of sites), there's other use cases (different sites/contexts) that don't neccesarily need resource groups.

When every context has technical resources like sitemaps (common use case, I guess?), you can use one resource group "Technical" and re-use that across the board to block users that only have a role of "Member" to see them, while they become available at "Super User". I'm counting one user group ("Administrator") and two roles (Member, Super User) there along with one resource group (Technical) which is only visible for Admin+Super User, by setting the following Resource Group ACL:

Resource group: technical
Context: mgr (we want this to apply in the manager only)
Minimum Role: 0 (super user)
Access Policy: Resource

If you were to force a resource group per user group you would complicate this scenario (sure, this is just one scenario and there's others that may be easier) as you would need to throw in another user group, add them to admin policy again etc etc etc.


I think the biggest problem is UX (too many tabs, too many grids, too many terms, too many policies, too many options => people go nuts) and user education vs rush - not the complexity. If you take a step back and think about what the stuff say, it can make sense. It's not something you can master in in 60 seconds, but I'd say less is more - don't touch what you don't need yet be specific.

Want to hide an element category from editor user groups in the manager? Then open up your admin user group, go to the Element Category and add your category, for the mgr context, with a minimum role of 0 or 9999 (doesn't matter usually) and choose the Element access policy. That makes sense right? You tell it exactly what you want (allow admins with this role to work with that category using the Element policy, and nobody else unless I say so) and should not take longer than a minute or so to click the right ones.


There'll be cases where it will be more work and be more complex, no doubt. I bet there's a few things impossible or overly complicated with this system (user-specific sections are a good example, though the tree_root_id as user setting can come to the rescue in that case), but some of the suggestions I read here, well, are how it works! Get rid of authority, and just use roles? An authority is a numeric representation of a role used to figure out inheritance of user rights.

Bottom line as far as I'm concerned?

Step back, formulate what you want to do, and start replacing your terms ("manager" becomes "mgr context access", "restrict access to X" becomes "allow other usergroups to access X") and you'll get the basics done in no time.

We can change the interface and make it easier to do that transition from what you want to do to the security aspects involved, but I don't think we're dealing with a flawed system.

Just my $0,02 (big one though o.O didn't plan for that to happen)

Mark, I hope you didn't think I was suggesting a forced connection between one user group and just one resource group. If so I was unclear. I meant to suggest leaving that part alone.

Like you, I have no trouble with the present system, but I don't think defending it is tenable in the face of so much evidence that it just doesn't work for many users.

With respect to authority levels, I don't object to having them tied to roles and letting users inherit the permissions of lower-authority roles. I just think the UI would be more intuitive if you specified permissions for a specific role (a la Evo) rather than an abstract policy + policy template that, for many, is mysteriously brought into the picture by somehow connecting a user group with a context, a minimum role (which is actually misleading because the numbers work backwards), and a policy using one of three different kinds of ACL entries.

IMO, it seems much simpler and more intuitive to say:

- What permissions do you want to assign to this role?
- What role do you want this user to have in this group?
- Remember that users will inherit the permissions of roles with higher authority numbers in this group.

I think I would put Manager permissions on one tab, resource permissions on another, and element permissions on a third, with some "master" permissions on each tab like allow_all and allow_none.

I don't think there's much that you can do now that couldn't be done with that system (though I could be wrong).

Different users could still have different roles in different groups and could still inherit permissions. It might be more work to set up for certain situations, but it would be work you could easily understand, and for most sites, I think it would make life infinitely easier, especially for less-technical MODX users.



---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html [ed. note: BobRay last edited this post 12 years, 3 months ago.]

I'm not sure who suggested the direct link between user groupsand resource groups... Just struck me as totally counterproductive.

I didn't mean to sound defensive and I definitely welcome improvements, but I want to have said that what people ask for already exiats. It's just called differently.

While there's some things to think through with the invincible super admin (rogue dev gone aawol?) thats one of the best ideas in this topic. And if we can lower some confusion by ditching authority from the screen outside of creating a role I think it would be great.

EDIT: Whoops, sorry for the 6 double post! My phone kept reporting 404 so I resubmitted a few times before giving up.. guess it did work [ed. note: markh last edited this post 12 years, 3 months ago.]

It seems ACLs are a stumbling block for many, and the worst thing that could happen for MODX now that it is building momentum, is to pick up a bad reputation of being difficult to work with because of it. Hopefully we can make ACL creation simpler and also generates a better understanding of it.

So, I'm going to have a shot... I've been thinking about this idea of simplifying the process of ACLs, and have made a little prototype form page that allows you to set permissions for an Access Policy. Before we go any further can I just point out that I am aware I am not addressing some of the bigger issues here that need to be solved for wizards, or applying this to specific use cases but, who knows, it might be a stepping stone on the way there.

Just looking at the huge list of permissions settings it seems they could be more easily handled by categorising and grouping, so thats what I have done. And to avoid having to go these settings one by one, I've allowed turning on and off sets. We start by giving blanket access for different categories of permissions eg 'Use Chunks' - which will allow you to view/create/delete/update/save chunks, but if we want, we can also refine these settings - its just a click deeper.
Hopefully, this makes it easier to establish broad patterns of permissions, but retain the granularity.

Categorising

As many of the settings relate to showing menu items and pages in the manager, it seems obvious that if we can group all of them into this system, we get an already familiar structure for people to work with.
If you give access to a group to access, upload or use files, you should naturally have access to the files tab in the left nav by default, the same for resources or elements. For this reason, I have put all settings to do with resources, objects and files under the Manager Left Nav area, under their respective tab view setting.

Though this works in most cases, for some settings it seems unclear whether they should be grouped by the objects they relate to or where they sit in the menu (eg create_resource - in menu under Site, or with resource functions in Left Nav?).

I don't consider myself an ACL expert, so if I've missed something important, or not understood the consequences of a setting, please point it out, and offer a solution if you can. As an example, there are some settings which I dont even understand why they exist - like why you would want to restrict logging out of the manager? (or perhaps this is more to do with the display of that item in the manager site menu??)
And what is the difference between 'database' and 'view_sysinfo' - both say System Info page?

HTML
All input names use the actual system setting names, other than new ones I have created which form a global switch for a group. These input names start with 'GROUPCHECK_', and only serve the purpose of switching on and off several settings at once.

Questions
Should Object settings be abstracted away from this interface?
Arn't they implicit if you are using resources/elements?

I've put it on jsfiddle so anyone can mess with it:

http://jsfiddle.net/christianhanvey/UM5bN/4/

So the final question is, does this help make it any easier to manage Access Policies?

I think that'll definitely help making custom access policies easier and I support changing the very, very, very long list to some kind of tree. Tabs would be a bonus, though I think it's not even neccessary - just having the stuff grouped like that will make it a lot easier as-is.

It wont make the entire process of creating new user groups easier, but definitely the area of creating a new access policy.