Thanks, Dylan. Ultimately I decided to modify getRolesInContext(). It seemed like the easiest fix and will allow much more flexibility in the long run in creating new roles and users. From a design perspective, it doesn't seem clean or efficient to engineer around Zope's standard operating procedures. Why not change them instead? In short, my new getRolesInContext() executes in the normal fashion, except when passed an object with my classes' meta_types. In this case, it checks local roles explicitly assigned to the object and its parent only, then returns only the local roles shared by both object and parent. Now I have a much more file-system-like level of security management. Yeah! Dylan Reinhardt <zope@dylanreinha To: nwingfield@che-llp.com rdt.com> cc: Zope Users <zope@zope.org> Subject: Re: [Zope] Local Roles and Acquisition 09/09/2003 02:05 PM Please respond to zope On Tue, 2003-09-09 at 09:47, nwingfield@che-llp.com wrote:

I spoke of 'Viewer' and 'Editor' (actually I'm recycling 'Owner') roles. On my root folder, these are loosely mapped to the 'View' and 'Edit' privileges, respectively. Almost all of my methods are restricted to one of these two privileges using declareProtected().

OK.

The problem comes in when Zope combines the explicit local roles with any local roles granted on all parent objects, effectively granting a user more roles than it ought.

I'm not sure that's the only problem. It's easy enough to restrict acquisition of permissions. I think a bigger problem may be that you are defining roles coarsely. With only one editor role, it's going to be difficult to distinguish between "editor in one context" and "editor in another context". At a minimum, this sounds like a three-role system: - Viewer - Owner (default Editor) - Guest Editor If I understand you, everyone can view and owners can edit. On certain objects, you want to enable "guest" (non-owner) editing. To do this, create the GuestEdit role at the highest level it should apply and add it to the correct users' roles. If you want your guest editor list to be same for all objects that enable guest editing, you're pretty much done: just enable guest editing per object desired. On the other hand, if you want to define *who* has the guest edit role per object, that's going to be a lot more work. The standard way to do that would be to create a role for each desired permutation. :-) Depending on how many users and objects we're talking about, it may be worth thinking about creating a root-level method that has an Editor proxy role. This method could have one large mapping containing each object each user should be able to guest edit (or vice versa). Basic object permissions for inner objects are configured strictly and this method allows users to "pierce" the security for objects they should have greater access to. This solution isn't necessarily easy or foolproof, but might be worth considering if you're talking about a really large system with many different combinations of editors and objects. HTH, Dylan