Security setup "teaser"

The new security is killing me. I've really wasted a lot of time with this. I've read Bob's guide and seen the video and RTFM. Just when I think I've got a decent understanding, I'll lose all the docs on the front end. So I'd love to see if anyone has a bright idea of how to set this up:

I've got a medium size site (over 200 pages), with 4 levels navigation. We've got at least 2 main user groups (Editors and Publishers). In general, Editors will be responsible for editing levels 3 and 4, and Publishers are responsible for approval and publishing. When and Editor logs in, they should only see the resources they're allowed to edit, as well as the parent docs (but not be able to edit those). This is the main problem.

What's the best way to group the resources so that I can limit what the Editor has access to?

I'm assuming that the Editors and Publishers will be working in the back end and that none of them are members of the Administrator user group. This might get you close:

First, never use the 'web' context for a Resource Group Access ACL entry when the resource group contains resources that you don't want to hide in the front end. That will ensure that no resources in that group will be lost in the front end. Don't forget to add the admin Super User to all groups with a role of Super User.

Second, put all the resources the users shouldn't see at all in the Manager into a resource group. Then connect that resource group to the Administrator user group with a Resource Group Access ACL entry with a context of 'mgr' (policy: resource, miniumu role: admin Super User).

Third, put all the parent resources they should see but not edit in another resource group (don't put the resources they can edit in this group). Connect that resource group to the Admin group exactly as above. That will protect those resources, and at that point, they'll be hidden from the editors. Next, connect that resource group to the Editors user group with Resource Group Access ACL entry with a policy of "Load, List, and View" (context: mgr, miniumum role: editor).

That will let the Editors see those docs (and their children) but not edit them.

The resources they can edit haven't been protected in any way, so they should be fine as is unless you need to hide them from someone else.

Test everything at this point.

I'm not sure what you want the publishers to be able to do, but if they get full access to all those resources, just make sure they have an authority number lower than the editors and connect their user group to the parent resource group with a Resource Group Access ACL entry with a context of mgr, a policy of resource, and a miniumum role of Publisher. [ed. note: BobRay last edited this post 12 years, 4 months ago.]

Bob, thanks so much--this is helpful. i thought (maybe thru my own trial/error?) that web context was not only the public site, but also the web context node in the manager. let me test these out and i'll report my findings.

Bob, I think that's going to work well for us. The thing that drives me crazy is that the Super Admin doesn't really have super admin privileges when you create groups, b/c you always have to add it to the user group. Seems that Super Admin should never have to be added to anything.

The other thing that's kind of a negative is that I'll need to create a resource group for every combination of "view only parents". Fortunately, that's not many for this project but could be a ton if every top level resource had, say, 4-5 immediate children. I guess the other option would be to just let the Editor see everything in the site, but only edit his/her resource(s).

Great help. FYI, after reading the RTFM and your site, somewhere I was under the impression I always had to add "web" context to whatever resource acl i was creating. I'll go back reread those, now that I have a little better understanding.

Protecting resources in any way protects them from the admin unless the admin is either in the group or you create a separate Resource Group Access ACL entry for the Administrator group for each resource group. I find it easier to just add the admin to every user group I create, but YMMV.

The 'web' context *is* the front end with one exception. All users need one *Context Access* ACL entry for the web context in order to see web context resources in the tree.

OTOH, *Resource Group* Access ACL entries (and Element Category Access ACL entries) should never have a context of 'web' unless you're trying to restrict access in the *front end*.

ok, great. i understand (for now)