#196: GroupUserFolder removing
- Contents
- Proposed by
- Encolpe Degoute
- Proposal type
- User interface
- State
- being-discussed
Definitions
Motivation
There were and there are a lot of critical UI bugs around GroupUserFolder by PlonePAS. Because of these, several Plone release had to be delayed. We fix a lot of them in customer branch.
Assumptions
Proposal
The first point is to fix UI to use pure PlonePAS API:
- users and groups control panel
- members search form
- sharing tab
Then we can cover all these by some functional doctests to prepare GroupUserFolder removing.
To remove GroupUserFolder we need to replace 4 tools:
- portal_membership (yet done)
- portal_memberdata (yet done)
- portal_groups (to do)
- portal_groupdata (to do)
As PluggableAuthService and PlonePAS implements all we need, it's more a compatibility step we need to put a depreciation warning on these tools. The removing step should implements an utility that assemble all methods from historical tools and put a deprecation warning tools usage.
Implementation
Groups are already implemented in PlonePAS, then we have to give them a group property sheet based on user property sheet.
UI improvements are already deployed in a private branch.
Deliverables
Risks
GroupUserFolder is unusable since two major versions. There is no risk to remove it.
But, implementing a new portal_groups and portal_groupdata would preserve the same API and run the same tests. This could give some headache.
The
Progress log
Participants
Framework team vote
Introducing deprecation warnings, however, could be considered OK.
BTW: I'm somewhat confused here myself because as pointed out in the PLIP the GroupUserFolder isn't usable since a while anyway but I simply don't know whether it could be considered safe for removal is I cannot judge whether anything still might bepend on it (most notably 3rd-party add-ons which we have promised not to break in this release).
Framework vote
UI Cleanups
Do you prefer I do this in the trunk or in a bundle ?
Framework team vote