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

[Gary Poster]

On Jan 12, 2006, at 7:16 PM, Florent Guillaume wrote:

> Gary Poster wrote:
>> Primary problem:
>> We frequently want to know the full closure of group membership.
...
> +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 :)

:-) cool.

> 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).

I know what you mean--we've done that in Zope 2 also.

I think my change fits the need of computed groups fine: computed  
groups would be a part of the direct iterable of `groups` for a  
principal, from which the full closure (`allGroups`) would continue  
to be calculated.

The current IPrincipal interface has a bit of a problem for computed  
groups but is pretty close, I'd say.  Right now, the core principal  
interface in zope.security says that `groups` is a list.  A list that  
has an unremovable member--a calculated group--is a bit hacky to  
model, so you might want to have a different API for mutating the  
groups--or maybe it's *all* calculated and imutable.  If this core  
interface were restricted to say that `groups` is a readonly iterable  
(which would be sufficient for the security policies I know, AFAIK),  
and then another interface extended it to match the current interface  
(a list), then the core interface would allow other principal  
implementations to determine the `groups` value in other ways.

That change sounds good to me, but also sounds like a separate mini- 
proposal. :-)

Gary