resource groups question

I’m trying to set up a permissions schema that works like this:

1. EVERY resource will belong to a resource group, identified by its ultimate parent.
2. EVERY manager user will belong to a universal user group called "mgrUsers".
3. "mgrUsers" members should have basic "read-only" ability to see all of the resources from all resource groups in the tree, and open them to see their basic info (but NOT edit them).
4. Each of the resource groups from (1.) will also have a corresponding user group. Users who belong to that user group will have the ability to EDIT the documents in that resource group.

Does that make sense?

Lets say I have 4 resources in my web context root: "A", "B", "C", "D". Each of them belongs to a corresponding resource group, "A", "B", "C" and "D". All of the child resources under "A" also belong to resource group "A", and so on with child resources under "B", "C" and "D".

Every manager user will automatically be a member of the user group "mgrUsers", which will have resource policies for all 4 groups "A","B","C","D". The resource policies will allow users to 1) see those resources in the tree, and 2) when they click on them, be able to open them in a read-only manner.

If Joe is a member of user group "A", then when Joe logs in to manager, he should - in addition to being able to browse & view resources in groups "B","C" and "D" - also have full editing control over items in resource group "A".

Is this scenario obtainable?
If so, what do I need to do to get there?

You would basically need:

• A plugin to make sure Resources got the appropriate Resource Groups based on the ultimate parent when created
• A read-only Resource policy (load, list, view) you can give to mgrUsers for each Resource Group
• An editors (or full) Resource policy attached between each associated User Group/Resource Group

Let’s start there...

Sounds good so far.

Last Friday I seemed to have come up with a combination of permissions that gave me a nice read-only solution where I could click on an item in the tree and see information about it in the "resource" area of the manager screen... just not edit it.

Today I don’t seem to be able to recreate that. Load-List-View doesn’t seem to do it - if I try to click on a resource that is set up the way I described, I get "Error! Access denied." when I try to click on it in the tree. (LLV does let me see it in the tree though).

I created a "ResourceMinus" policy (duplicate of Resource policy) to use insead of LLV, to try to get the read-only effect. Seems that toggling the "Save" permission changes it from being editable to "access denied".

Thoughts?

Okay - some more developments.

Having "save" permission checked in the resource policy does seem to be required in order to get anything besides an "Error! Access Denied" message when clicking on a resource in that resource group.

However...
unchecking "edit_document" and "save_document" permissions (while leaving "save" checked) creates the "read only" view I was talking about. You can’t see the resource’s content field, but you can see Title, Alias, and basic information.

That’s exactly what I need!

Unfortunately...
The "edit_document" and "save_document" permissions are not part of the "Resource" policy... they seem to be context-level permissions.

(I tried adding them to the Resource policy template & then the Resource policy... but it did not have the desired effect).

Am I right that *verb*_document permissions cannot be applied at the level of a resource policy?

If so, this leaves me out-of-luck with what I’m trying to do. I can either give all manager users rights to edit all resources, or give them "Error! Access Denied" on all resources that aren’t "theirs". But not a friendly read-only view.

Additional Update:

Going back to using "Load List View" policy for resource groups that the current don’t own but should be able to view...

As aforementioned, if I click on one of those resources in the tree, I get "Error! Access Denied".

However...

If I right-click on the resource and choose "View Resource"... I get the read-only view that I’ve been looking for!

I guess this is because doing a regular-click on a resource is effectively saying "Edit this resource!" Where I was expecting it to mean "Edit this resource! Unless you don’t have permission -- in which case, View this resource!"

Is any of this making sense to anyone? At least it is making more sense to me today.

Yes, making sense James—I think it would be good to have the main action be View vs. Edit when a user has View but not Save permission calculated for a Resource.

I suppose somebody should file a feature request for that, right?