[Zope-CMF] [dev] local roles: new 'Change local roles' permission?

[Yuppie]

Hi!


Working on deleteMembers, I stumbled over the Local Roles methods in 
CMF. I'm not happy with the way action and methods are protected:

The 'Local Roles' action is protected by 'Manage properties' and links 
to folder_localrole_form.

Using folder_localrole_form, you need access to setLocalRoles() and 
deleteLocalRoles(), currently guarded by roles, not by a permission.

This is inconsistent (why 'Manage properties'?) and unflexible (no 
chance to control access by a permission). I propose to add a new 
'Change local roles' permission to guard them all.


Regarding a checkin on yuppie-deleteMembers-branch Tres Seaver wrote:
> You have changed the use case here:  the original code allows
> non-managers (in your case, users without the 'ManageUsrs' permission)
> to "share" their roles with others (e.g., I can create a document, and
> then add you as an "Owner").  I don't know whether the skins surfaced
> this feature, however, so this use case may not be important to anyone. 
> Hmmm, probably not for "normal" content, but the folder_local_roles form
> can do this.
> 
> Perhaps we could make it::
> 
>     security.declareProtected(View, 'setLocalRoles')
>     def setLocalRoles( self, obj, member_ids, member_role, reindex=1 ):
>         """ Set local roles on an item """
>         member = self.getAuthenticatedMember()
>         my_roles = member.getRolesInContext( obj )
> 
>         if (_checkPermission(ManageUsers, obj)
>                or member_role in my_roles):
>              for member_id in member_ids:
>                  ....

I broke that use case accidentally (and so thanks to Tres for catching 
this), but I'd propose an other solution:

setLocalRoles() should be guarded by

1.) a 'Change local roles' permission in the context of the object
- and -
2.) the roles the user is allowed to set

<code>
     if ( _checkPermission(ChangeLocalRoles, obj)
          and member_role in self.getCandidateLocalRoles(obj) )
</code>

Combined with a small change in getCandidateLocalRoles this should work 
with all use cases.


Any thoughts? If there are no objections, I'll change it that way.

Cheers,
	Yuppie