[Zope3-dev] a note on groups and roles

[Martijn Faassen]

Lennart Regebro wrote:
> From: "Martijn Faassen" <faassen at infrae.com>
> > The concept of a group meaning that everybody in that group has the
> > *same* role assigned to them is extremely useful all by itself. You can
> > assign a class of users a role (like 'allowed to access this part of the
> site').
> 
> Yes, sure. But how often to that class of users map to something real, that
> is not actually a role, and not an organisatonal entity? Most of the time,
> it's an organisational entity. And in organisational entities, you typically
> have different roles for different people.

For read/viewing access in large organizations, you typically have
large classes of users (in organizational entities) that you want to
give viewer access somewhere. You really don't want to give these people
individual roles; these are really large groups of people ("all employees",
"all members of the site", "all students in department Y"). I don't see 
workgroups as a useful concept for those cases, as it would entail
having to manage all the members of the workgroups individually,
which is exactly what you want to avoid.

Small parts of a organizational unit where write access is involved have 
other demands where workgroups become more interesting. If you have
the same set of 10 users that need access in the same way to multiple 
objects, I can imagine a case where you'd want workgroups. Even in that
case I wonder how you would encode "this subobject of this particular
object can only be accessed by person A, B, and C" in a workgroup. You
could invent your own permissions or roles here, but that doesn't sound
entirely right in all cases..

I can faintly imagine cases where you want groups to be part of workgroups,
but this seems to getting near too-powerful-to-understand for end users.

> > I don't think conflating the workgroup concept with the group concept
> > this way is very useful if what I say above about workgroups and groups
> > offering different functionalities is true.
> 
> Well they to. Groups are simply a way to assigning local roles to several
> users at once. Workgroups is a way to let role assignments be based on your
> organisational position. That is, you don't have to make a separate group
> for people who are bosses, you instead add them into their organisational
> group, as a boss,

What does it mean to add them "as a boss"? Do you give them a role that the
boss needs?

>  and the will have boss priviliges wherever the group is
> active. So, yes, the functionality is different.
> 
> I can imagine that there may be cases where you want all over the
> organisational group to have an additional role as well, though. Even if I
> actually can't think of such a case right now. :-)

I think I listed some use cases above. I mean, that's the way Silva is
used right now.

> > security hooks in the name of efficiency. For instance, if group
> membership
> > is defined globally, you only need to calculcate what group a user is in
> > once per request, not once per object (which you'd need to do if there
> > were hooks or locally defined groups).
> 
> Yes, but in both cases groups membership are defined globally, so that
> doesn't make a difference. The problem with completely generic hooks is that
> it's hard to make efficient shortcuts. You may have to calculate the roles
> from top to bottom, instead of as now, from the bottom to the top, and then
> bail out once you found a matching role.

Bailing out is hard if you can actually 'block' roles in various locations.
In addition it's hard when the role-permission mapping is different in
a different location. You really need to check everything in that case.

Steve and I were speculating about some highly efficient datastructure and 
some algorithms that globally manage security information about objects. 
This seems to be the route to the fastest system, but it raises of course
a number of other problems (keeping this information in sync is one).

Perhaps an alternative is a very sophisticated caching system for security
information.

Regards,

Martijn