Ticket #9347 (closed PLIP: wontfix)
registration policy
Reported by: | dokter | Owned by: | dokter |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Unknown | Version: | |
Keywords: | Cc: | plip-advisories@… |
Description
Proposer: Duco Dokter
Seconder: None as yet
Motivation
Registration of new users in Plone is very restricted in functionality: there is the choice between unsupervised registration or no registration at all. For registration that should go through approval, one needs to install Membrane/Remember.
Assumptions
There is a need for at least two registration policies:
- unsupervised registration
- registration with approval
Proposal & Implementation
Add configlet for registration policy to the site configuration options. Allow admin users to decide upon a registration policy. Add a portlet for registrations that need approval. These users need to be stored in a utility, and will be created upon approval.
Deliverables
- New configlet in site setup for registration providing choice of join policy
- Utility for storing non-approved users
- Portlet for join policy with approval, showing pending registrations
- Unit tests
- Localization
- Documentation
Risks
Default behavior will be same as current situation. No risk assessed.
Participants
- Duco Dokter, dokter
- Kim Chee Leong, kcleong
- Kees Hink, khink
Progress
None as yet.
Change History
comment:2 Changed 7 years ago by erikrose
As I said on #9310, I like the idea.
- We should use the existing workflow framework rather than inventing something new.
- We have member data spread all over the place at the moment. Showing a good understanding of which way we're moving and moving with it would increase the chances of me voting yes on the implementation.
- I'd like to see the config UI end up in the same configlet as, say, the "Let members choose their own passwords" setting and other member-centric things.
- It's worth considering whether it makes sense to represent the pending users as full-fledged content objects. Consider, it, but don't consider it too hard; we almost certainly wouldn't want to suddenly make 50,000 content objects in an LDAP situation, for instance. The objects could be deleted upon approval, but that would be a surprising behavior compared with what usually happens when content is approved or published.
Assuming the above, FWT vote +1.
comment:3 Changed 7 years ago by raphael
FWT vote: -1 for core
but I'd appreciate this as an add-on.
comment:5 Changed 7 years ago by erikrose
Because this could be done pretty unintrusively and because the implementation might want change once we have dexterity's lighter-weight content objects (dexterity), I think we should do this as an add-on for now. I'd be happy to reconsider this for 5.0, when we might be able to do a full members-as-content implementation without such drags on performance or storage.
Changing my FWT vote to -1.