[Zope3-dev] a note on groups and roles

[Lennart Regebro]

From: "Martijn Faassen" <faassen at infrae.com>
> 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.

Why would it have that effect? All students in department Y would be set as
"Students" in the "Department Y" workgroup.

But OK, I suddenly ten minutes ago realize that "roles" and "roles" are not
the same thing. (Great eh?). A pure workgroup implementation, as outlined in
my proposal, would require you to redefine the permission settings for a
role in differen places, and we don't want that. Roles tend to be set up not
as roles in an organisation, but as the permission set used to perform a
specific action, such as reading, publishing, creating. The workgroups idea
is to let you define one persons organisational position, like teacher,
student, and so on. What you need is to map that organisational position to
a set of actions.

I'm gonna sleep on this insight. I really would like this extra
ortogonality.

> > 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?

The original idea was to add them as the "boss" role. I have to think on
this, however.

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

Well, don't. Just store it centrally, and that's i, right?. :-)