Quote from: BobRay at May 31, 2010, 01:34 PM
(now my brain hurts) 
You are making mine hurt too. I think you are over-analyzing this a bit.
The target of the ACL is the object to which the "core" permissions apply. Again ONLY load, save, and remove.
That said, Elements and Resources themselves are not actual targets of an ACL, IOW their policies are loaded by proxy from Categories and Resource Groups respectively.
So with that in mind, let’s answer your specific questions:
Quote from: BobRay at May 31, 2010, 01:34 PM
in the Administrator Policy attached to the mgr Context Access ACL entry for a user:
-- The user has "save" but not "save_chunks" -- can he save chunks?
-- The user has "save_chunks" but not "save" -- can he save chunks?
He cannot save chunks in the first scenario, but can in the second. The target of the Context ACL’s are modContext objects and load/save/remove only apply when operating on the modContext objects.
Quote from: BobRay at May 31, 2010, 01:34 PM
Now, add in the Element Category ACL with the chunks in the named category (it’s the only category):
-- The user has "save" and "save_chunks" in the Administrator Policy attached to the mgr Context Access ACL entry, but not in the Resource policy attached to the Element Category ACL - can he save chunks in the category?
First, Resource policy? Create a policy for your Element Categories. Regardless it depends on what is in the policy attached to the Category. Does it have load and save? If so, then yes, he can load and save both the modCategory object and the modChunk (derivative of modElement). In this case, the load/save/remove core permissions apply to both the Category objects and the Element objects they are related to. In addition, policies are inherited from parent Categories, which also must be take into consideration.
The short answer is yes, if you attached the default Resource policy, he can save chunks in the category.
Quote from: BobRay at May 31, 2010, 01:34 PM
-- Reverse the above -- can he save chunks in the category?
save_chunks in the manager will override specific object permissions like load, save, remove. The manager application and core processors are coded to respect these permissions explicitly. If he has load and save in the policy attached to the category (or a parent category) of the chunk, it doesn’t matter this time, because he can’t save_chunk in general.
Quote from: BobRay at May 31, 2010, 01:34 PM
If a user has both a mgr Context Access ACL entry and a web Context Access ACL entry (necessary to see resources in that context in the tree), will the permissions in the *web* ACL entry affect what the user can do in the Manager with resources in that context (e.g. edit, save)? IOW, if the user has "save" and "save_chunks" in the web ACL entry but not in the mgr ACL entry:
Other than the core permissions of load/save/remove, which affect being able to "see" a Context in the manager, the other permissions in a context access ACL define what a user can do "from" that context. IOW, a front-end administration extra operating in the "web" Context would determine it’s permissions to perform actions in the core processors from a "Front-End Administration" policy attached to the Web context. It might be best to start separating the Context ACL policy permissions from the core permissions that define whether you can "load/save/remove" the Context from any context including the mgr. Back to that on the Read, Read-Write, Read-Write-Remove discussion.
Quote from: BobRay at May 31, 2010, 01:34 PM
-- Can he save chunks in the web context in the manager?
Context ACL’s are global to actions taken in that context, so if the policy attached to the mgr context has save_chunks, the user can save chunks in the mgr. Attaching save_chunks to the web context is currently meaningless, unless you execute a core processor from the web context (IOW front-end editing).
Quote from: BobRay at May 31, 2010, 01:34 PM
-- If he doesn’t have those permissions in the category, can he save chunks in the category?
If a category is protected by at least one ACL entry, then he if he doesn’t have save on the category (or a parent category) then he will not be able to save chunks in the category (unless he is a member of the User Group attached to that ACL entry.
Quote from: BobRay at May 31, 2010, 01:34 PM
-- Can he save chunks *not* in a category?
Same as the first, scenario. This is determined only by a core processor permission, save_chunk, based on the context the action is being taken in, i.e. the mgr.
Quote from: BobRay at May 31, 2010, 01:34 PM
Re the Read, Read-Write, Read-Write-Remove idea, would the current specific permissions (save, save_chunks, view_snippets, etc.) be removed from the standard policies? If added back in, would they override? I.e. if a user had just "Read" permission, would adding save_chunks to the policy allow the user to save chunks? I think I like the idea.
This is more to differentiate between object permissions and content management permissions, which I think is where most of the confusion comes in. If we take Context ACLs out of the equation, all we are talking about is object permissions, or permissions that apply to specific instances of an object. Though these can also apply to Contexts, Contexts also define an entirely different set of permissions that define what core content management activities can be performed from that Context. So instead of load/save/remove for Contexts being defined in your default Administration policy, they would be defined and applied separately as a Read, Read/Write or Read/Write/Remove policy. This would isolate the permissions based on how they apply and avoid any confusion about a Context ACL save permission having anything to do with saving anything other than the Context object itself.