Can't get User X to be able to edit Page X

126 Posts

debussy Reply #1, 15 years, 9 months ago

I’m beating my brains out trying to make this work, I can’t find anything in the forums pertaining to Revo and my particular problem (perhaps I’m not searching for the right terms), and the video posted in the documentation seems to have only gotten me in more trouble.

Very simply: my client is a non-profit that will have a section on their site for various chapters/groups. When a chapter/group gets created, then they need to create a single page (in a subfolder on the site) that one person from that chapter/group can edit (NOT delete, publish/unpublish, or create children items for).

So... tell me where I’m mucking it up here:

Chapter X gets Page X inside the chapters folder.
Page X is assigned to Resource Group X.
User X is assigned to User Group X with a role of Editor (100).

Editing the User Group X (this is where I get lost):

Context Access:
context: web; min role: Member 9999; policy: Load Only
context: mgr; min role: Editor 100; policy: Editor

Resource Group Access:
resource group: X; min role: Editor 100; policy: Object; context: mgr

I can get the user to login, but they can’t see the resource tree. If you go directly to an ID, then you can edit it (any ID!).

Another confusion, I think, is what the permissions themselves do...
for instance, why is there a "save" option separate from all of the individual permissions, i.e., "save_resource", "save_snippet", etc.
what is the difference between list, load, and view? To what things do those apply?

Ultimately I would like to be able to get Frontpage working to make things much easier on the end users.

MODX Staff
10,725 Posts

opengeek Reply #2, 15 years, 9 months ago

You should assign a customized Resource policy to the Resource Group/User Group with permissions you don’t want them to have removed.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

126 Posts

debussy Reply #3, 15 years, 9 months ago

Set Up Resource

1. Create resource X (as child of resource "chapters")
2. Create resource group X
3. Assign resource X to resource group X

Set Up User(s)

4. Create user "Bob"
5. Create user group X
6. Create role "Chapter Editor" with value of 100
7. Assign user "Bob" to user group X with role of "Chapter Editor"
8. Assign site admin to group X with role of "Super User"

Set Up Policies

9. Duplicate Content Editor policy as "Chapter Editor"
10. Disable the following permissions in "Chapter Editor" policy:
[list]
[li]delete_document
new_document

[/li]
[/list]

Assign Policies

Updating user group X:
[list]
[li]11. Add context:
[list]
[li]context: web
minimum role: Member 9999
access policy: Load Only

[/li]
[li]12. Add context:

context: web
minimum role: Chapter Editor 100
access policy: Chapter Editor

[/li]
[li]13. Add context:

context: mgr
minimum role: Chapter Editor 100
access policy: Chapter Editor

[/li]
[li]14. Add resource group:

resource group: X
minimum role: Chapter Editor 100
access policy: Object
context: mgr

[/li]
[li]15. Add resource group:

resource group: X
minimum role: Chapter Editor 100
access policy: Object
context: web

[/li]
[/list]
[/li]
[/list]

With this setup, the manager shows the resources tab, but not the tree... So... I had to go turn on the "list" permission. (Odd that that’s not on by default for "Content Editor")

So, now that you can see resources... You are able to edit any resource.

I figured that since I was setting edit_document access to the whole context that I should also try duplicating the "Chapters Editor" policy into "Lister" with the "edit_document" permission disabled. I then changed the context assignment policies for Chapter Editors to Lister. I thought that would let me see (but not modify) any records, but that the resource group policy would add the ability to edit whatever pages belonged to it. However, when I do all this, the only thing that changes is that I can no longer edit any documents--including the one I need to.

EDIT: I had mentioned this in my draft, but deleted it before posting: When I go to add a Resource Group Policy to user group X, the only options I have for policies are "Load Only"; "Load, List, and View"; "Object"; and "Resource".

After that, I even tried manually going into the database in the table modx_access_resource_groups and changing the policy numbers to my custom "Chapter Editor" policy... In the resource group access tab, the name of my custom policy showed up just fine, but when updating the policy, it reverts to the id number, and, again, only lists the aforementioned options as selectable. I flushed permissions, and still couldn’t edit resource X (or any resource).

[/list]

126 Posts

debussy Reply #4, 15 years, 9 months ago

I also forgot to mention that I did install 2.0.5 yesterday morning... I was able to select custom policies on resource groups w/ 2.0.4...

24,544 Posts

BobRay Reply #5, 15 years, 9 months ago

2.0.5 uses policy templates. To add a custom permission, you need to add it to the appropriate policy template.

In 2.0.5, you can assign the Administrator policy for all Context Access ACL entries
and the Resource policy for all Resource Group Access ACL entries.

Then, just uncheck the permissions you don’t want the users to have (flushing permissions and checking as you go).

It might help you to know that the Context Access ACL entries control what the user can do in general in the Manager.
The Resource Group Access ACL entries control what they can do with resources in the group.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

126 Posts

debussy Reply #6, 15 years, 9 months ago

Thanks... that helped a lot! I was able to set the custom policy on the resource once I created it using the right template.

Still unable to edit though...

From your post and my results I’m gathering this... the resource group ACL is unable to override the lockdown on editing that the context ACL is placing.

I’m guessing I will have to create a second resource group, "Locked," and put everything that shouldn’t be editable into it, open up the context setting to allow editing, and then let the "Locked" resource group keep the rest of the site from being edited. Does that sound right? If there’s a better way, then someone can save me, potentially, a lot of work...

Otherwise... I’m off to search docs and forum now for how to assign new resources to a resource group by default... (hopefully it’s just a system setting).

24,544 Posts

BobRay Reply #7, 15 years, 9 months ago

Quote from: debussy at Dec 14, 2010, 12:48 PM

Thanks... that helped a lot! I was able to set the custom policy on the resource once I created it using the right template.

Still unable to edit though...

From your post and my results I’m gathering this... the resource group ACL is unable to override the lockdown on editing that the context ACL is placing.

I’m guessing I will have to create a second resource group, "Locked," and put everything that shouldn’t be editable into it, open up the context setting to allow editing, and then let the "Locked" resource group keep the rest of the site from being edited. Does that sound right? If there’s a better way, then someone can save me, potentially, a lot of work...

Otherwise... I’m off to search docs and forum now for how to assign new resources to a resource group by default... (hopefully it’s just a system setting).

Yes, users without edit permission in the Context ACL can’t edit anything, regardless of what rights they have in a Resource Group ACL.

You’re also right that resources not in any group are not protected, except by the Context Access ACL limitations.

One possible solution is the tree_root_id user setting, which takes a comma-delimited list of IDs. The user can’t see anything above those resources in the tree (although I think they could edit them if they can guess the ID and enter the appropriate URL in the Manager).

Otherwise, I think you do need to put all resources in a group and protect them by creating a Resource Group ACL entry for the Administrator group. Check out the Batcher plugin, which I think will allow you to assign them to the group all at once. You might also want a plugin that assigns new docs to that group be default.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

126 Posts

debussy Reply #8, 15 years, 9 months ago

Update: That did the trick!

To summarize for anyone else trying to figure this out:

--> Context: set to maximum access that a user needs

--> Resource Group X: set to allow user to do whatever you need (in my case, save only)

--> !!! All other resources must be put into a different resource group that disallows access to the user !!!

... now, onto the problem of automatic resource group assignment...

126 Posts

debussy Reply #9, 15 years, 9 months ago

Quote from: BobRay at Dec 14, 2010, 01:23 PM

You might also want a plugin that assigns new docs to that group be default.

Does such a plugin already exist?

24,544 Posts

BobRay Reply #10, 15 years, 9 months ago

Quote from: debussy at Dec 14, 2010, 02:22 PM

Quote from: BobRay at Dec 14, 2010, 01:23 PM

You might also want a plugin that assigns new docs to that group be default.

Does such a plugin already exist?

Probably not as a package, but it would look pretty much like this (linked to the OnDocFormSave event):

$groupId = 12;  // or whatever -- ID of the resource group - consult the modx_documentgroup_names table
$resourceGroupResource = $modx->newObject('modResourceGroupResource');
$resourceGroupResource->set('document_group',$groupId);
$resourceGroupResource->set('document',$id);
$resourceGroupResource->save();

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting