[Zope3-dev] Re: full closure of group membership

[Florent Guillaume]

Gary Poster wrote:
> Primary problem:
> We frequently want to know the full closure of group membership.  The  
> groups attribute of zope.security.interfaces.IGroupAwarePrincipal is  a 
> list of groups to which the principal directly belongs.  The full  
> closure--including the groups to which the principal's groups belong,  
> for instance--must be calculated by any piece of code that needs it.
> 
> Secondary problem:
> The description of  zope.security.interfaces.IGroupAwarePrincipal.groups 
> does not  sufficiently clarify that it is *not* a full closure.
> 
> Consideration:
> zope.security.interfaces.IGroupAwarePrincipal has been around for  
> awhile, and probably should not be materially changed (i.e., to  
> redefine or add an attribute).
> 
> Solution:
> 
> 1) Clarify the zope.security.interfaces.IGroupAwarePrincipal.groups  
> description: change from
> "List of ids of groups the principal belongs to"
> to
> "List of ids of groups to which the principal directly belongs"
> 
> 2) Add an additional interface to zope.security.interfaces interface.
> 
> class IGroupClosureAwarePrincipal(IGroupAwarePrincipal):
>     allGroups = interface.Attribute(
>         'a readonly iterable of the full closure of the principal's  
> groups.')
> 
> 3) Make the principals in zope.app.authentication implement  
> IGroupClosureAwarePrincipal.  First cut of 'allGroups' would probably  
> be to make it be a lazy property, returning a tuple of the full closure.
> 
> Risks:
> Some might be unhappy that allGroups is not a hook point, but a  
> convenience: that is, it will be a full closure, not an opportunity  to 
> be clever to redefine how group membership is calculated.

+1, a long time ago I suggested something similar because in the CPS 
framework of groups we need knowledge both of direct membership and 
transitive closure (we have a getGroups method that's the direct groups, 
and a getComputedGroups that's the transitive closure and is used for 
instance when we have groups of groups).

I'm still not using the zope 3 principal framework but at some point I 
know I'll need it in zope 3 too :)

Do you think your interfaces fit the need of "computed" groups? I'm not 
sure if the meaning of "computed" is clear but I can expand on that if 
it's not (for instance, it could be for the case where groups exist 
dynamically according to some computation on the prinicpal's properties).

Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com