Ticket #9347 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 7 years ago

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:1 Changed 7 years ago by raphael

  • Owner set to dokter
  • Cc plip-advisories@… added

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:4 Changed 7 years ago by ldr

Great as an add-on, but not for core.

FWT vote: -1

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.

comment:6 Changed 7 years ago by alecm

I think only a very small percentage of sites require member approval. Therefore, I believe this would make a desirable add-on package, but it does not belong in the core at this time. I'm not particularly passionate about this though:

FWT vote: -0

comment:7 Changed 7 years ago by esteele

  • Status changed from new to closed
  • Resolution set to wontfix

Rejected for 4.0 by FWT vote.

Note: See TracTickets for help on using tickets.