[Zope3-dev] Groups and Roles *not* interchangeable

[Martijn Faassen]

Phillip J. Eby wrote:
[snip]
> Given that supporting applications based on non-ZODB data sources is also 
> relevant to 10x, I'd have to say that computed roles and groups are *not*, 
> repeat *not* interchangeable.  As Shane and I have both pointed out, groups 
> can't do what computed roles can, but computed roles *can* do what groups 
> can.

While I have a proposal for computed local roles sitting in the fishbowl
myself and I had a discussion with Shane where pointed out they wouldn't
be very catalogable (and I argued about the importance of this) some
weeks ago, I need more specific examples of what computed local roles
can do that groups can't. I suspect others do too. :)

Let's see. Object A has two types of things you can do to it, View and
Edit. The permissions needed to do those things are associated with roles,
let's call them the ViewRole and the EditRole. 

Now, if user has metadata Foo, the user should get the View role, and if
user has metadata Bar, the user should get the Edit role as well.

With computed groups, we could say somewhere globally that all users with
metadata Foo are in group X,  and those with metadata Bar are in group 
Y (and group X as well). Now we can say to object A group X has local role
ViewRole and group Y has local role EditRole. Group membership can
change dynamically, and all members in the groups get the right roles.
Nice.

With computed local roles, you could say in object A that you gain role 
View if you have metadata Foo as user, and role Edit if you have metadata Bar.
Works too, nice.

But, computed roles can do something more, as object A could determine
the mapping of metadata to local role on other information as well, such
as instance data. If I press a checkbox in the object, its behavior may
for instance be reversed, and now metadata Foo means EditRole while Bar
means ViewRole.

You cannot do this with groups, as they are global. 
What you could do with groups to reach a similar effect in this case is to
switch the mapping however, so that the groups get the reversed role.
Still, this sounds less fine grained. But I need more use cases to 
show whether one needs this finegrainedness..
 
> Btw, I might also note that LoginManager also supports group-to-roles 
> mappings now, in the sense that you can create dummy roles that mean group 
> membership.  There is a role-to-role mapping that you can then set up that 
> converts "group roles" into "real roles".  So I wouldn't say that 
> supporting the concept of groups necessarily involves a great deal of 
> complexity.

I definitely need to investigate LoginManager, as I need this kind of stuff
in Zope2..

Regards,

Martijn