On Tue, Mar 19, 2002 at 04:11:05PM +0100, Lennart Regebro wrote:
> I also want groups! But I want a different kind of groups, that I call
> "workgroups" just to distinguish them from all other types of "groups". :-)
> I don't know if it's possible implement this compatibly in 2.x, and I can't
> judge if there is any problems in implementing one type of groups in 2.x and
> then switching in 3.x. And of course, I'm worried that implementation of
> groups in 2.6 will lessen the possibilities of getting workgroups into 3.x.
> A workgroup is a set of users, just like I understand that NuxUserGroups
> are. But you set up a workgroup just like you would set up the local roles
> for a folder, ie, you do not only assign users to the workgroup, *you also
> assign roles to them within this workgroup*.
> When setting up a workgroup you don't get access to anything but the
> workgroup itself. But, you can then add any
> number of workgroups to a Zope folder, and the users in that workgroup would
> get the roles they were assigned in the workgroup to that folder.
> That way you still get the grouping and indirection that you get from otehr
> grousp, but you also get a greater automatic granularity in that grouping.
> So, in technical terms a workgroup is macro of role definitions. When you
> add a user to the workgroup and give him a Reviewer role, he will get the
> Reviewer role at all the folders where the workgroup is added to the
> workgroup list. The workgroup "Boss" will get the "Boss" role in all the
> places where this workgroup is added.
> With normal grouping, you typically have one group per department, and give
> that department access to a couple of parts of the database. Then you have a
> group of the Bosses that have more access. But usually this means that all
> the Bosses have Boss access everywhere, which is not necessarily what you
> So, even if it is very tempting to let Florent implement the local roles
> blacklist instead of doing it ourselves :-), I'd rather wait for workgroups
> than standard groups. In any case Johan and me would be very happy to help
> Florent and the others at Nuxeo implement it groups and blacklists.
I needed a generalization of this scheme (and so ended up writing my own
We manufacture parts which are controlled by second parties, but bought
primarily by third parties. I will call these parties Manufacturer,
Brand Owners, and Contractors.
I now have two kinds of administrators, and two kinds of users. There
are unrestricted administrators and users. Since this really is
enforced only at the user folder level (normal zope machinery is used
elsewhere), a quick description is that an unrestricted administrator
may create, modify or destroy any user or Brand Owner Name, and may
associate any list of Brand owner names with any user. Any unrestricted
user has a flag designating him as such and it is expected that
application code check the flag and permit access to the contents held
for Brand Owners.
Restricted Administrators may create new users, modify users, or delete
(some) users. However, any user they create may have only a subset of
their brand owner name list (and their normal zope permissions).
They may remove any of their brand names from a user that has one or
more of the brand names under their control. They may delete users that
have brand names only under their control. They may also create other
administrators, subject to the subset restictions.
Restricted Users have a brand list associated with them. Application
logic can use this brand list to filter content.
The restricted administrator is a big deal to us. If this takes off, we
will not be able to properly control the set of Restricted Users (at
Brand Owners and Contractors). Failure to do so could lead to legal
exposure, so by creating Restricted Administrators who are Brand Owners,
the contrl (and thus most of the legal exposure) can be shifted back to
the Brand Owner.
> Best Regards
> Lennart Regebro
> Torped Strategi och Kommunikation AB
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -