Resource Groups in MODx Revolution...

I mean package up:
admin
publisher
editor
contributer
member

as roles/user groups/resource groups without any users or resources, then:
build a site
add users
add content to pre-defined resource groups
add users to pre-defined roles

just to remove having to remember the 30 trillion different steps, half of which are hidden behind right click menus, that otherwise seem required even for simple things.

It’s definitely doable. The problem is that different people would want different sets of user groups (and different permissions for them) and different sets of resource groups. If everyone were creating a standard blog, it would be easy, but MODx can be used for so many different things that I wouldn’t be comfortable designing a generic package of user groups, policy templates, and resource groups.

That said, I have thought of creating a wizard that would guide you through the process and create them for you.

Quote from: BobRay at Feb 22, 2011, 07:34 AM

That said, I have thought of creating a wizard that would guide you through the process and create them for you.

That would be great and will save enormous headaches for many (:

Quote from: BobRay at Feb 18, 2011, 07:47 AM

Quote from: jusmeig at Feb 17, 2011, 11:42 AM

Hi guys, I have been told by a colleague of mine that these steps did not work for him. He is using the latest revo build.

Um ... what steps?

These, I wrote them a few weeks back

This is exactly what I did (I think I did all of what you said above??):
1. Create new "editor_resource_group"
2. I dragged 2 docs in then clicked
3. Security -> Access Controls
4. I created a New User Group "Backend_Restricted"
5. I updated this guy
6. I gave Context access to mgr and web with the following settings:
min role: Editor 1 (which I created)
access pol: Content Editor (as this has most of what I want my user to do)
7. Resource Group Access I added a new entry:
Resource Group:editor_resource_group
Minimum Role: Editor 1
Access Policy: Resource
Context: mgr

How, exactly, did that "not work"?

That said, I have thought of creating a wizard that would guide you through the process and create them for you.

If the wizards of modx would be so generous to create a wizard for permissions... I bet a lot of us hobbits would be overjoyed! Great idea, where do I donate?

Quote from: jusmeig at Jan 07, 2011, 10:41 AM

Quote from: BobRay at Jan 07, 2011, 07:05 AM

Bear in mind that tree_root_id doesn’t really protect the resources. It’s fine for naive users who can be trusted, but if a user can guess the correct URL for editing a resource in the Manager, they can still do it.

Yeah I don’t think I’m going to do that.
OK so I think I got it working after much toil, blow by blow account below.

1. I created a new Resource Group called "Developer Resources".
2. To this I added all the resources with snippets that I wanted to hide from my client.
3. I now created a new Role in Security -> Access Controls -> Roles [I called it "Editor" and gave it a priv of 1]
4. I created a new User Group called "Client Editor" in Security -> Access Controls -> User Groups
5. I now created a new User in Security -> Manage Users -> Add User. I added this user to the user group "Client Editor" with a Role of "Editor"
6. I now edited the User Group called "Client Editor" created in step 4.
7. In Users tab I added the user I created in step [5]
8. In Context Access I setup the following:
Context: mgr | Minimum Role: Editor | Access Policy: Content Editor (ensures this guy can login to manager)
Context: web | Minimum Role: Editor | Access Policy: Content Editor

9. In Resource Group Access I setup:
Resource Group: Developer Resources | Minimum Role: Editor | Access Policy: Load Only | Context: mgr (means this guys cannot see these docs in mgr context....which is what I want)
Resource Group: Developer Resources | Minimum Role: Editor | Access Policy: Load Only | Context: web

10. Save

Still with me....

11. Edit the Administrator User Group now.
12. In Resource Group Access add the following:
Resource Group: Developer Resources | Minimum Role: Super User | Access Policy: Resource | Context: mgr (means this guys can see these docs in mgr context, and still edit etc)
Resource Group: Developer Resources | Minimum Role: Super User| Access Policy: Resource | Context: web

13. Save and then Flush permissions.

DONE!! I now have an admin user who can see everything, and an Editor user who sees all documents but the ones I hide from them in my "Developer Resources" group.

I’m off to get a coffee
I think the thing that did not sit well in my head was the fact the admin can hide documents from themselves, this to me seems very odd (I am the admin after all) I make the rules!!!

Thanks guys for replying to this thread!

Hello-

This worked great, thank you for posting this! One thing I’m having an issue with is when I hide a Resource (web page) in Resource Groups to the new ’Developer Resources’ group that was created, it makes that web page inaccessible from the internet.

I don’t want my ’Content Editor’ to have access to the Home page. Any thoughts on how to fix this?

Thank you,

Quote from: Hlight at Mar 24, 2011, 01:09 PM

That said, I have thought of creating a wizard that would guide you through the process and create them for you.

If the wizards of modx would be so generous to create a wizard for permissions... I bet a lot of us hobbits would be overjoyed! Great idea, where do I donate?

I agree!!!

...One thing I’m having an issue with is when I hide a Resource (web page) in Resource Groups to the new ’Developer Resources’ group that was created, it makes that web page inaccessible from the internet.

I don’t want my ’Content Editor’ to have access to the Home page. Any thoughts on how to fix this?

Thank you,

Hi
Same issue here. I thought I might be starting to sort of understand the permissions system, but then that happened.
Another issue, it seems that some CSS styles were hidden in front-end web pages until I logged in to the manager as admin.
In the end I just had to make my editor a full administrator and ask him to try and ignore the elements tab, and most of the top menu, and leave the parent resources alone, and remove all resources from all resource groups. Now the site is fine again, but I’m seriously considering leaving CMS behind altogether and going back to PHP.
...

If you use a Resource Group Access ACL entry with a context of ’mgr’, it won’t affect access in the front end.

If you don’t want to restrict access to a group’s resources in the front end, never create a Resource Group Acesss ACL entry with a context of ’web’.