Ticket #9292 (closed PLIP: wontfix)
Group management delegation
Reported by: | glenfant | Owned by: | glenfant |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | General | Version: | |
Keywords: | Cc: | plip-advisories@…, grahamperrin@… |
Description
Motivation
Plone is a well suited to provide publication spaces to many groups and many users. In such situations, site managers are frequently asked to add/remove members to groups.
In order to ease the site manager's job, he should have tools to delegate the management of each group to one or more group members.
Such members - whatever's their global roles - would have access to a control panel that manages the membership of the groups they're entitled to manage.
Assumptions
Today, users and groups management are protected by permissions "Manage users" and "Manage Groups" and are not suited to this, groups being not content objects. Thus we can't grant "Manage users" for a particular group to such and such user.
Implementation
Actually I have no particular idea for achieving this (through PAS rules, using pseudo content types for groups, other silly or clever ideas ...), but if the functional model has enthusiastic readers, I shall work on a design and code for this PLIP.
Risks
If the implementation doesn't grant a particular role to users who can manage group members, care should be taken to the security.
Change History
comment:2 Changed 7 years ago by glenfant
My fellows Maik Roeder (aka 'roeder') and Jean-Mathieu Grimaldi (aka 'macadames') are about to release plone.app.pgmd that does this job on a legacy Plone 3.x.
https://svn.plone.org/svn/collective/plone.app.pgmd/
Many thanks to them.
comment:3 Changed 7 years ago by macadames
The package has been renamed (plone.app.... is reserved)
https://svn.plone.org/svn/collective/collective.groupdelegation/trunk
More information here :
http://pypi.python.org/pypi/collective.groupdelegation/0.1
Many thanks
comment:4 Changed 7 years ago by alecm
+1
This is a very good idea and it looks like there are plenty of willing developers. We need to make sure that security is strictly enforced for this functionality.
comment:6 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:10 Changed 7 years ago by davisagli
A lot depends on the implementation, but I am very +1 on this idea.
FWT vote: +1
comment:11 Changed 7 years ago by raphael
FWT vote: +1 (but the implementation will of course be critically reviewed)
comment:12 Changed 7 years ago by calvinhp
FWT Vote: +1
comment:13 Changed 7 years ago by esteele
Approved by FWT vote.
comment:17 Changed 7 years ago by glenfant
Progress status posted there... https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/plips/plip9292-group-mgt-delegation.txt
comment:18 Changed 7 years ago by glenfant
PLIP ready for preliminary review.
But just seen that Eric Steel is working on a complete refactoring of the users/groups control panel here https://svn.plone.org/svn/plone/plone.app.controlpanel/branches/esteele-usersconfig
Will need to rework all this later ;)
comment:21 Changed 5 years ago by rossp
- Status changed from assigned to closed
- Resolution set to wontfix
PLEASE READ THIS AND RE-OPEN VALID PLIPS!
As we launch the new PLIP process we'd like to see which PLIPs:
- are still appropriate/needed
- still have owners/proposers/champions
- still have available implementers
If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.
This would be a very useful feature. I have no idea what the right architecture is - it might require moving to a world where our members + groups are true (workflowable) content objects.