Create a new user with manager access permission in Modx Revolution

A previous thread started by T J Hearne http://modxcms.com/forums/index.php?topic=57620.0 about new user access permissions came to an end with a 13-point plan for creating a new user which seemed to make it perfectly clear how to create a new user with permission to access the manager and do stuff like edit resources. That made me hopeful. Followed the plan to the letter, but I still couldn’t use my new users name and password to log into the manager. Found Bob Ray’s long article http://bobsguides.com/revolution-permissions.html and learned a lot from that and started feeling hopeful again. Picked up the tip about going to System Settings and tweaking Allow_Root to let new users create resources (but they have to be able to log in before they can contemplate creating resources and I hadn’t got that far yet). Tried again. Failure.

Here is the process as I have understood it so far (presented as if I know what the heck is needed and am in a position to give advice to others). Somewhere there is a mistake. Where?


1. A new user must have a role to play, so...

First create the role that the new user will play. Go to Security -> Access Controls, click the tab "Roles" and click the option "Create New". Give the role a name, description and authority number (e.g. Editor, Permission to edit content, 9).

2. A new user must belong to a group, so...

Next to the Roles tab in the Access Controls section is a tab marked "User Groups". Click it and click the option to add a new user group. Give the group a name.

3. The new user in this group will need to have access to the back end of Modx (the manager), so...

While still in the "Access Controls" section with the list of user groups displayed, right-click the name of the new user group and select "Update User Group". This calls up the options to determine what people in this group can actually do. The "Context Access" tab is absolutely crucial. N.B. If the new user group is not explicity given access to the manager context, users in that group won’t be able to log into the manager admin area. So under "Context Access" click "Add Context" and select "mgr". Do the same for "web".

4. Once the role and the group have been defined you can say who exactly is going to play that role in that group, so create the new user. Click Security -> Manage Users and click the option "Add New User". Under "General Information" you can set the username and password and contact details. Then under "Access Permissions" you can specify the group the user will belong to and the role s/he will play in the group. (Once the group has been added, right-clicking on the name of the group calls up the option to update the details, which includes setting the role to be played in that group.) Click "Save".

5. So the new settings take effect, click Security -> Flush Permissions.

6. Log out then log in with the username and password of the new user to test that things are as they ought to be.

I did all that, opened up a new browser (just in case) and tried to log into the manager with the new user’s details. Result: Access denied ("You do not have the proper access policy permissions to view this page. If you feel this is in error, please contact your systems administrator").

Where did I go wrong?

The request for help fell on stony ground this time. But no bad feeling because the forum has been a real help in the past.

I persevered, though, and made it in the end.

There was a lot of stabbing in the dark so if someone else is having the same problem, I am not in a position yet to write a clear step-by-step account of how it should be done.

The above steps are, I think, correct. What was missing seemed to be the following: After creating the user group, the role and then the user, there is a final step to bring all that together.

Assuming the new user has been made a member of the Administrator user group, go to Security -> Access Controls to see the list of user groups (again!). Right-click the Administrator user group (assuming that is where the new user is going to play ball, and choose "Update group".

Click the "Context Access" tab to see the table linking contexts, roles, and access policies. Click "Add new context". There you can choose the mgr context, the role given the new administrator and the corresponding access policy.

Flush Sessions (not just permissions, it seems). Test the new log in.

Belatedly found the details from the Revolution documentation. They are doubtless correct, but the crucial final step to tie together user, role, group and access policy wasn’t clear to me.

There must be a simpler way of setting up a new user. And I think there ought to be one for all those sites that are only going to have one or two ususers needing access to the backend, so you could define the username and password for the new user and immediately tie the user to a pre-set access policy.

Step one: Define access policy.

Step two: Define new user

Step three: Tie new user to access policy.

The plethora of groups, roles and policies gave me a real headache. Presumably it is a real boon for mega-organisations using super-massive websites but for those of us building mostly brochure sites it seems like there should be a fast-track method in parallel.

Yes, I second the fast track method... and it should also be intuitive to use this "fast track" approach this stabbing in the dark - look at the official docs - more stabs in the dark - more docs - more stabbing - more forum questions - more reading more more more... and I’ve read and re-read Bob’s guides and the offical docs and my head is spinning...

all this user, user group, resource group, context access, access control lists, access policies, access policy templates, roles... by the time I get five steps into it I forget where I’m at haha I guess what I’m trying to say is that in modx revolution it is extremely difficult to visualize how all the pieces for access control / permissions fit together.

okay, I’m done venting, back to learning... maybe if someone made a nice visual diagram of how all of these esoteric objects relate with one another (I will when able)

Update: Think I’ve got it sussed now. Here is the technique.

Okay, let’s imagine you have a client called Doreen who needs to take the reins of her website. She needs access to most of the resources and she needs to be able to create new resources (because there is a little news or reviews feature that needs each snippet of news or each review to go on its own resource). How to set it up? Here’s one way (for MODX Revolution 2.1.3).

1. Just so Doreen can create new resources go to System -> System Settings. In the settings for Authentication and Security find Allow root. Set it to Yes.

2. Create a User identity for Doreen. Security -> Manage Users. Click New User and
create and set name, password, email, active status.

3. Next we need to create a role for Doreen to play. Security -> Access Controls -> Roles. Create a new role (say, Editor) with an authority of, say, 10.

4. Don’t ask me why, but users with roles also have to belong to groups, so create a group for Doreen. Security -> Access Controls -> User Groups. Create new group called Editors Group.

5. Doreen needs to be in that group (she isn’t yet), so (with the list of user groups visible) right-click the Editors Group and select the option to add a user to the group. Choose Doreen’s id and give her the role of Editor.

6. The problem with the MODx role that you created is that so far it is just a name. No permissions or prohibitions have been specified to define what Doreen can and can’t do as an Editor in the Editors Group. So we have to create a Policy. Two tabs along from the User Groups tab (Security -> Access Controls) is a tab that says Access Policies. Click it. There is already a Content Editor policy but you will probably find it is not permissive enough, so select it and right click it to choose the option to update it. Go down the list of permissions selecting the ones you want Doreen to have. (I’m going to add all the file permissions, new_document_in_root, publish_document, purge_deleted, save, undelete_document, unpublish_document, view_unpublished). Click Save.

7. Now we have to tie the access policy and the role to the group. Get back to the list of user groups: Security -> Access Controls -> User Groups. Right click on the Editors Group and select "Update Group." Then click the Context Access tab. Click Add Context, and select the mgr (manager) context, select the Minimum Role: Editor, and choose the Access Policy: Content Editor.
If you leave it there, for some reason Doreen won’t see any resources in the Manager area when she logs in, so repeat the previous procedure by clicking Add Context and select the web context this time together with the same role and policy as before.

Click Save.

We could leave it there, but there are a few resources that we don’t want Doreen messing with, so lets create a Resource Group for those and deny her access to them. Security -> Resource Groups. Click Create Resource Group. Call it Super Admin Only. Drag the resources to be hidden into that group.

To give yourself sole access to those resources go back to Security -> Access Controls to see the list of user groups (again). Right Click the Administrator group (of which you will be a member by default) and select the option to update the group. Click the Resource Group Access tab and then click Add Resource Group. Choose the SuperAdmin Only group, and then choose Minimum Role: Super User, Access Policy: Resource, and Context: mgr.

Click Save.

Chances are, if you refresh the resource tree now the resource you wanted to give yourself privileged access to disappears. Fear not, get it back by clicking Security -> Flush Permissions. Phew!

Okay, click Security -> Flush Sessions just to log out and trash any bureaucratic dross that might have accumulated.

Log in with Doreen’s id and password to check that everything is as it ought to be.

Sounds like you have it licked.

Thanks for the nice tutorial. I’m sure it will help a lot of people.

Here are the two most common stumbling blocks that people run into:

1. The "Access Denied" message when the user tries to log in to the Manager usually means that the user group your user belongs to does not have a Context Access ACL entry with a context of ’mgr’.

2. If the user can log in but the tree is empty, it usually means that the user’s group does not have a Context Access ACL entry with a context of ’web’.

FYI, there is some relatively new stuff at Bob’s Guides that might also help people in similar situations: http://bobsguides.com/revo-security-tutorials.html

Hey Bob can you chime in here and take a look at what we might be doing wrong.

http://modxcms.com/forums/index.php/topic,67482.msg379270.html#msg379270

Thanks.

Quote from: Hlight at Mar 23, 2011, 10:41 PM

okay, I’m done venting, back to learning... maybe if someone made a nice visual diagram of how all of these esoteric objects relate with one another (I will when able)

http://modxcms.com/forums/index.php/topic,64266.0.html

Quote from: benmarte at Aug 13, 2011, 01:46 PM

Hey Bob can you chime in here and take a look at what we might be doing wrong.

http://modxcms.com/forums/index.php/topic,67482.msg379270.html#msg379270
Thanks.

I don’t see anything obvious. You should probably start a new topic since that one sort of got hijacked and it looks like you have a different problem. Make sure all the resources in question are published and not protected by any permission rules.

This tutorial helped me sooooo much. thank you!

I tried WebDesig's tutorial but all I get is "Error! Access denied". Even when the User Group has mgr Context Access. Maybe I'm missing soemthing