Revolution 2.0.0 pl Permission Confusion

I am trying to learn the permission in v2.0 and some of it is starting to make sense and some of it is frustrating me.

First it appears that to create an Access Policy you should copy/duplicate the Administrator policy and then delete what you do not want the user group to access. This is not initiative to me at all, my suggestion on this would be once you click Add to have a drop down of the Policies to copy, with the Admin as default. This would at least start you in the right direction rather reading a bunch of stuff to find this out.

Here is what I do not understand, why do the other default groups do nothing? For example lets take the Access Policy "Resource". The name suggests to me that you would only have access to Resources, which is what I am trying to do for a group. If you only assign a user group the Context of mrg and Access Policy of Resource and regardless of minimum role, they are denied access to any part of the manager. And the same with all of the default Access Policies, you are denied access to the manager.

If the these Access Policies groups don’t give you access why are they there? They are just confusing! If they are for some part of the core for plugins, they should be labeled accordingly.

My suggestion is to remove these or make the do what their names suggest, like give Access to Resources for the one labeled Resource.

Quote from: jgulledge at Jul 29, 2010, 02:47 PM

I am trying to learn the permission in v2.0 and some of it is starting to make sense and some of it is frustrating me.

First it appears that to create an Access Policy you should copy/duplicate the Administrator policy and then delete what you do not want the user group to access. This is not initiative to me at all, my suggestion on this would be once you click Add to have a drop down of the Policies to copy, with the Admin as default. This would at least start you in the right direction rather reading a bunch of stuff to find this out.

Here is what I do not understand, why do the other default groups do nothing? For example lets take the Access Policy "Resource". The name suggests to me that you would only have access to Resources, which is what I am trying to do for a group. If you only assign a user group the Context of mrg and Access Policy of Resource and regardless of minimum role, they are denied access to any part of the manager. And the same with all of the default Access Policies, you are denied access to the manager.

They actually make sense, you just got off on the wrong foot. First, there’s nothing inherently wrong with modifying the standard policies. It’s just that they’re there, in part, to be examples of a case with full rights and once you modify them, you no longer have that.

As for the separate policies, policies don’t control access so much as they control what you can do and see. Access is controlled mainly by the existence of an ACL entry. The policy attached to that entry determines what you can do and see with what you’ve been given access to (through the specific permissions in the policy).

The Administrator policy determines what administrator *actions* you can take in the Manager (e.g. create new users, save resources, alter security settings, etc.). The other two policies (resource and element) determine what you can do with specific *objects* (e.g. save them, delete them, edit then, publish them, etc.). ACL entries relating to specific resource groups and category access, should always use a policy based on the resource or element policy. Context access policies (designed to control access to a specific context -- e.g. the mgr context) should be based on the Administrator policy.

At some point, the docs will start catching up with the code and such things will be clearer. (and there’s my yet-to-exist book) .

Thanks for the reply, but I don’t think it is as much a documentation issue as it is an overly complex issue.

Here is my perception of the permissions schema. First they are made to be extremely large and flexible in what can be configured. This is a good thing except the problem is that they are very complex and there is no good default Policies besides the Admin and the other 4 that don’t work and they are not intuitive to a beginner.

My suggestion would be to create some default policies that ship with Modx. I think it would be extremely helpful and make adoption of Modx more plausible. How about a default Policy for the Content Editor/Manager - this Access Policy would see the Resource tree objects and be able to manage them add/edit/delete and maybe the Files tree. Then this would give a good starting point rather then going through and deleting 40 permission elements that I don’t know what they mean anyway.

The site that I wish to convert to Modx is very large and we need to create a lot of user groups and sub groups, those groups are mostly some variant of a Content Editor or Content Submitter.

Quote from: jgulledge at Jul 29, 2010, 04:19 PM

Thanks for the reply, but I don’t think it is as much a documentation issue as it is an overly complex issue.

Agreed, but complex stuff requires extra-good documentation and we’re not there yet.

Here is my perception of the permissions schema. First they are made to be extremely large and flexible in what can be configured. This is a good thing except the problem is that they are very complex and there is no good default Policies besides the Admin and the other 4 that don’t work and they are not intuitive to a beginner.

I’m not sure what you mean by "4 that don’t work." Which four? All the policies work, AFAIK. Do you mean they don’t serve your purposes? There are the three main standard policies: Administrator, Resource, and Element. And there are the two minimal policies: Load Only, and load/list/view, which basically give users read-only rights.

My suggestion would be to create some default policies that ship with Modx. I think it would be extremely helpful and make adoption of Modx more plausible. How about a default Policy for the Content Editor/Manager - this Access Policy would see the Resource tree objects and be able to manage them add/edit/delete and maybe the Files tree. Then this would give a good starting point rather then going through and deleting 40 permission elements that I don’t know what they mean anyway.

The site that I wish to convert to Modx is very large and we need to create a lot of user groups and sub groups, those groups are mostly some variant of a Content Editor or Content Submitter.

It’s a great idea, but it’s hard to know exactly what people would want. Different sites have different definitions of what a Content Editor and a Content Submitter can do. If you include all the possible things they might want, your sort of back where we are now.

You’re definitely right that the individual permissions need to be documented better.

Another thing that would help a lot would be a way to delete multiple permissions from a policy in a single step.

What I mean by "4 that don’t work" is the other default Access Policies.

Attached is the default list of Access Policies. If you pick any of them but Administrator you do not have permissions to even view the Manager area.

Quote from: jgulledge at Jul 30, 2010, 07:34 AM

What I mean by "4 that don’t work" is the other default Access Policies.

Attached is the default list of Access Policies. If you pick any of them but Administrator you do not have permissions to even view the Manager area.

You do know that you can have more than one ACL entry for a user group, right?

When you give users access to the mgr context with a policy of Administrator (in a Context Access ACL), they have full rights to *do* everything you can do in the manager.

Because the web context is protected via the ACL entry for the Aministrators group, other users won’t see any resources in the tree until you give them that access too -- even if they have full rights to the Manager.

When you create a Resource Group Access ACL to connect a resource group to a user group, those resources are protected. Anyone in a group with a policy of "Resource" can do anything and everything to those resources. Until you give them the Resource policy rights rights, however, they have the permission to do stuff in the Manager, but not to do specific things with those objects. That takes the resource policy. So, for protected resources, The Administrator policy won’t work without the Resource policy and vice versa.

For Elements, it’s exactly the same except using a category instead of a resource group.

The last two policies are for users you want to severely restrict so they can see the resources, but not do anything with them.

Hope that makes sense.

Thanks I think I got it. Here is a diagram of how I understand it to be.

I posted a short video here about permissions: http://jgulledge.wordpress.com/2010/07/31/learning-modx-tutorial-2-permissions/.

Quote from: jgulledge at Jul 31, 2010, 11:18 AM

Thanks I think I got it. Here is a diagram of how I understand it to be.

It looks right to me, I’m glad you got it worked out.

I think it might be clearer if your verbs had objects (e.g. Assign them to what?).

Here’s another way to look at it:

Assign User to a User Group
Assign a Document to a Resource Group
Give a User Group Access to a Context
Give a User Group Access to a Resource Group
Give a User Group Access to an Element Category

I created a script that will create 5 different Access Policies and give them the appropriate permissions. It runs out side of the manager and I just put everything in an array so you can move them around if you wish. To me they are very helpful to separate the permissions and then it makes it much easier to fine tune them.

I have all permissions divided into 5 Access Policies:
- Basic Manager (mrg) Access => This allows a usergroup basic login rights to the mgr,
- System, Security and Tools (mrg) Access => This builds on the Basic Manager and give right to manage the System, Security and Tools.,
- Element Rights => This allows a usergroup the rights to add, edit and delete Elements,
- Resource Rights => This allows a usergroup the rights to add, edit and delete Resources,
- File Rights => This allows a usergroup the rights to add, edit and delete Files