Ticket #9310 (closed PLIP: fixed)
User registration process more flexible
Reported by: | dokter | Owned by: | dokter |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Unknown | Version: | |
Keywords: | Cc: | plip-advisories@…, khink |
Description (last modified by dokter) (diff)
Proposer: Duco Dokter
Seconder: Alexander Limi, David Convent
Motivation
Registration of new users in Plone is very restricted in functionality: the registration fields are a fixed set. Adding extra fields to the form implies manually changing the HTML of the form, and customizing the registration_form template and process.
Assumptions
There is a need for more flexibility in the registration fields: one would like to be able to ask for a phonenumber, or company name, for instance.
Proposal & Implementation
Add configlet for registration fields. Allow admin users to determine what fields need to be filled in upon registration. These fields will be required on the registration form. Change the join form into a dynamic form that will use the configuration settings to display the fields to the user to be able to register.
Deliverables
- New configlet in site setup for registration providing two settings:
- join fields
- Dynamic form for join process
- Unit tests
- Localization
- Documentation
Risks
Default behavior will be same as current situation. When migration from an older Plone version si performed, the issue with join_form adaptations needs to be addressed. Most probably a warning is enough for a detected join_form customization.
Participants
- Duco Dokter, dokter
- Kees Hink, khink
- Huub Bouma, huub_bouma
- David Convent, davconvent
Progress
Some of the work has been done at the Baarn 2009 sprint.
Change History
comment:2 Changed 7 years ago by PythonHack
+1 I'd hate to see the difficulties of a solid member approval implementation hold up the implementation of customizable member properties.
comment:3 Changed 7 years ago by jonstahl
Both of the ideas in this PLIP are extremely desirable; however, I agree with the above commenters that making user profile fields more easily configurable is a much more urgent need than member approval policies.
comment:4 Changed 7 years ago by pupq
User profiles fields come up all the time in class. +1 to that. From my students, at least, workflowable membership is very rarely asked about. +0 to that.
comment:5 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:6 Changed 7 years ago by optilude
I think for the cusomisable fields and forms part of this, we should look at plone.app.memberschema. I wrote a comment to #9311 explaining how this may work.
For the approval stuff, I think we should find a way to use DCWorkflow for this. That doesn't have to mean we apply the workflow to content objects representing members (which is what membrane does). But if we're trying to model an approvals process, I'd rather we found a way to use DCWorkflow than invent something separate.
comment:8 Changed 7 years ago by MatthewWilkes
I think the risks are probably higher than you've suggested, but this is an important missing feature.
FWT Vote: +1, lets see how it goes.
comment:9 Changed 7 years ago by rossp
FWT vote -1. There's not enough known about the implementation and not enough exploration of the risks for me to feel good about this.
comment:10 Changed 7 years ago by alecm
Because this PLIP still includes the member workflow portion, which I believe should be split into a second PLIP:
FWT vote: 0
comment:11 Changed 7 years ago by davisagli
FWT vote: +1. Both features discussed here are desirable, particularly the configurable member properties.
However, my sense is that we don't yet have consensus as a community regarding how these things should actually be implemented. So I would highly encourage you to start with some discussion of that on the plone-developers list before starting to implement this. If I see that that discussion has occurred and that you have implemented this in a way that reflects that discussion, I'm much more likely to vote positively for the final implementation.
Martin's plone.app.memberschema does seem like a good approach, but it also requires z3c.form. And I'm not sure we should introduce z3c.form to core unless we're ready to rewrite our CMFFormController and formlib forms using it. (Which I'm generally in favor of, but we need someone to do the work, and I'm scared it's going to make forms harder to customize for integrators.)
comment:12 Changed 7 years ago by optilude
David,
Just a quick note: it'd be quite possible to factor the z3c.form bits out of p.a.m and put them into another package, or conversely factor the PAS stuff out into a separate package (plone.memberschema?).
To be clear: p.a.m contains a PAS plugin that allows you to register member data by schema, and a form based on the schemata listed there. Making a formlib form of the same wouldn't be hard (even if I'm not personally very interested in doing it).
comment:13 Changed 7 years ago by raphael
I'd like to see this split into 2 PLIPs
- Flexible member schema: +1
- Member approval support: -1 for Plone core; this is the perfect use case for an add-on
comment:14 Changed 7 years ago by calvinhp
FWT Vote: -1 I'd like to see the user data portion of this separated into its own PLIP that I'd give a +1. It seems like a more reasonable core feature than the workflow of members.
comment:15 Changed 7 years ago by erikrose
FWT vote: +1. Go ahead and have a shot. Here's what will determine my vote on the implementation:
- As optilude said, if you're going to workflow things, figure out a way to use the existing workflow framework.
- We seem to 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 will make me really happy. :-)
comment:17 Changed 7 years ago by dokter
Removed the registration policy part. This will be added as a second PLIP.
comment:18 Changed 7 years ago by esteele
Marked Approved
comment:22 Changed 7 years ago by khink
comment:23 Changed 7 years ago by khink
comment:24 Changed 7 years ago by khink
comment:25 Changed 7 years ago by dokter
comment:26 Changed 7 years ago by dokter
comment:27 Changed 7 years ago by dokter
comment:28 Changed 7 years ago by khink
comment:29 Changed 7 years ago by khink
comment:30 Changed 7 years ago by esteele
Per email to Dev list, implementer will not be able to complete this PLIP before the deadline: http://n2.nabble.com/work-on-PLIP-9310-stalled-tp3363213p3363213.htm
comment:32 follow-up: ↓ 33 Changed 7 years ago by rossp
Review added in r29614, doesn't work for me, hope it can be fixed but -1 until it can be
comment:33 in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 7 years ago by rossp
comment:34 in reply to: ↑ 33 ; follow-up: ↓ 36 Changed 7 years ago by rossp
- Cc khink added
Replying to rossp:
Replying to rossp:
From khink's email:
The error you mentioned should be fixed now.
I still get the "Error: REQUEST" error on the new @@join_form. I double checked that I had the latest SVN versions of everything including your branches. Please confirm that the plone-coredev/plips/plip9310-flexible-user-registration.cfg works in a fresh environment before reporting it fixed again so I can re-run the load tests against it.
Also, please document the rest of your work here in the ticket.
Finally, can you address the rest of the feedback in my review?
comment:35 Changed 7 years ago by esteele
Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.
comment:36 in reply to: ↑ 34 Changed 7 years ago by khink
Replying to rossp:
Replying to rossp:
Replying to rossp:
From khink's email:
The error you mentioned should be fixed now.
I still get the "Error: REQUEST" error on the new @@join_form. I double checked that I had the latest SVN versions of everything including your branches. Please confirm that the plone-coredev/plips/plip9310-flexible-user-registration.cfg works in a fresh environment before reporting it fixed again so I can re-run the load tests against it.
Also, please document the rest of your work here in the ticket.
Finally, can you address the rest of the feedback in my review?
I'll test better the next time. I'll get back before the end of the weekend with an update.
comment:37 Changed 7 years ago by khink
The "Error: REQUEST" happens after the new user is created. This happens finally in 'Products.PlonePAS.plugins.role.getRolesForPrincipal', which assumes it has a 'REQUEST' on it. It doesn't. Also, the method takes an optional 'request' argument, which doesn't seem to be used.
I'm not sure what the idea behind this is. The attached patch fixes the "Error: REQUEST". It simply tests if 'self' has a 'REQUEST' attr, before trying to fetch it. As this may have consequences, i would like a second opinion on this.
Index: Products.PlonePAS/Products/PlonePAS/plugins/role.py =================================================================== --- Products.PlonePAS/Products/PlonePAS/plugins/role.py (revision 97735) +++ Products.PlonePAS/Products/PlonePAS/plugins/role.py (working copy) @@ -112,8 +112,9 @@ # the ones he got through his groups. In this case, the # '__ignore_group_roles__'= True should be previously pushed # in the request. - if not self.REQUEST.get('__ignore_group_roles__', False) and hasattr(principal, 'getGroups'): - principal_ids.extend( principal.getGroups() ) + if hasattr(self, 'REQUEST'): + if not self.REQUEST.get('__ignore_group_roles__', False) and hasattr(principal, 'getGroups'): + principal_ids.extend( principal.getGroups() ) for pid in principal_ids: roles.extend( self._principal_roles.get( pid, () ) ) return tuple( unique( roles ) )
comment:38 Changed 6 years ago by rossp
Revisiting my review. Some things have been fixed:
- Error: REQUEST
- field help
- existing/old join_form
Still not addressed:
- default to current behavior
- portlets
- configlet location
The three remaining all seem so trivial to accomplish. Unfortunately, I think only the configlet location is optional since the first can be considered to be actual breakages.
I'm very reluctant to vote -1 for merge, but at this point we have to vote based on things as they are, so unless esteele wants to address these trivial issues while he's merging or accept late contributions, then I have to vote -1. :(
comment:39 Changed 6 years ago by rossp
Also note that since this one creates a new join_form view, and #9330 modifies the join_form.cpt skin object, if both of these PLIPs were merged, it would be a non-trivial merge.
BTW, I hope this one can make it into Plone 4.1 if it doesn't make it into 4.0
comment:40 Changed 6 years ago by khink
Addressed these issues:
- portlets;
- place of configlet;
- default behaviour;
Ready for merge.
comment:41 Changed 6 years ago by rossp
I see that the location of the configlet has been changed and that the login portlet no longer appears. Excellent. But the default behavior is still different from current, which is probably the most important.
comment:42 Changed 6 years ago by rossp
comment:43 Changed 6 years ago by rossp
comment:44 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes - Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:45 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9614.
comment:46 Changed 6 years ago by khink
Changes have been merged into Plone 4.0 branch.
Details:
* Merge the used branches: * merge https://svn.plone.org/svn/plone/Plone/branches/plip9310-flexible-member-registration/ into https://svn.plone.org/svn/plone/Plone/branches/4.0/ (r30489) A merge in two parts, [28069:28274] and [28275:30488], because r28275 was a merge of the current 4.0 branch unwise back into the plip-branch. (Unwise, in retrospect.) * merge https://svn.plone.org/svn/plone/plone.app.users/branches/plip9310-flexible-member-registration into https://svn.plone.org/svn/plone/plone.app.users/trunk/ (r30468) Also done: * use z3c.autoinclude (r30493) * modify rendering so it looks like other user/group configlets (r30494) * fix import of PloneMessageFactory (r30492) * merge https://svn.plone.org/svn/plone/plone.app.controlpanel/branches/plip9310-flexible-member-registration into https://svn.plone.org/svn/plone/plone.app.controlpanel/trunk/ (Merge not needed (trunk has 'utils' module), so not done.) * merge https://svn.plone.org/svn/plone/plone.app.form/branches/plip9310-flexible-member-registration/ into https://svn.plone.org/svn/plone/plone.app.form/trunk/ (r30463) (No real merge, just added '<metal:block define-slot="authenticator">' to pageform.pt.) * Merge buildout: * Added plone.app.users to sources.cfg (r30490) * Added plone.app.users to Plone 4.0's egg dependencies (r30491) * Made sure buildout uses trunk version of plone.app.form * Checkout and run new version of buildout * Delete PLIP9310-branches (r30503, r30504, r30505, r30506)
comment:47 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed
comment:48 Changed 6 years ago by maurits
I get several failures like the next because home page and location are not on the join form by default anymore. Perhaps this worked on the branch but not after merging to trunk? Could this have something to do with the new Plone theme?
$ bin/instance test -s plone.app.users ... File "/home/maurits/buildout/plone-coredev/4.0/src/plone.app.users/plone/app/users/tests/flexible_user_registration.txt", line 10, in flexible_user_registration.txt Failed example: form.getControl(name='form.location') Exception raised: Traceback (most recent call last): File "/home/maurits/shared-eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/doctest.py", line 1361, in __run compileflags, 1) in test.globs File "<doctest flexible_user_registration.txt[line 10, example 3]>", line 1, in <module> form.getControl(name='form.location') File "/home/maurits/shared-eggs/zope.testbrowser-3.6.0a2-py2.6.egg/zope/testbrowser/browser.py", line 755, in getControl control, form = disambiguate(intermediate, msg, index) File "/home/maurits/shared-eggs/zope.testbrowser-3.6.0a2-py2.6.egg/zope/testbrowser/browser.py", line 54, in disambiguate raise LookupError(msg) LookupError: name 'form.location'
I am trying to integrate this plip with plip #9214 (see ticket #9643) and having successful tests before I start would be nice. This is with r30654. I did some test and pep8/pyflakes fixes after that which did not result in extra test failures. And I have begun integrating that plip anyway. Sorry if I step on anyone's foot. :)
comment:49 Changed 6 years ago by maurits
(In [30720]) Integrated the 'email as login' plip (#9214). Made the email field and widget ascii-only, otherwise you get validation errors or unicode errors when trying to log in. Always show the email field. Made the code more robust against input errors, at least for the username and email fields. Fixes #9643, refs #9310 and refs#9214.
comment:50 Changed 6 years ago by maurits
Okay, I made the changes necessary for proper handling of the email login plip in the new @@join_form. See r30720 for details.
Some remarks for clarity follow.
I made sure the email widget is always displayed, as this field has always been required. If wanted I could do this only when the email address is used as login (#9214), but there are more cases, like for the 'mail_me' field.
The email field is now an ASCIIField and uses an ASCIIWidget, as non-ascii emails are not accepted by the email regular expression in the registration tool, and even if you have only ascii the input value is still unicode and when using such an email address as login you run into a unicode error when hashing the username in plone.protect.
I protected the code against a few InputErrors (WidgetInputError, ValidationError, ConversionError). For instance, adding accented characters in the username resulted in a traceback instead of a friendly widget error shown in the form.
Oh, and a ConflictError was caught and turned into a status message, but I have changed that to raise the Exception so Zope can handle it, which is how those ConflictErrors should be handled AFAIK.
In CMFPlone I changed tests/emaillogin.txt to use the new @@join_form; tests are passing; changeset is r30721. The same may need to be done for csrf.txt, but I am already getting errors on the unchanged file, so I am trying not to get side tracked there. :-)
comment:51 Changed 6 years ago by esteele
A note on some changes I've recently made that relate to this PLIP... I've moved @@join_form to @@register, changed text and class names accordingly. The "groups" field has been moved to a new view, @@new-user, that is intended to be the manager-facing registration form linked from the users preferences panel. @@new-user will also display the password fields, regardless of the 'Let users select their own passwords' site setting.
+0
This is a great idea, but it will require a fair amount of updated infrastructure to support member approval. Is this usecase so common that an add on like membrane isn't the right solution? In my experience most sites want either tight control of membership (potentially with existing single-signon integration) or essentially open limited membership. Open membership subject to approval seems like an edge usecase.
Perhaps the configurable properties part of this PLIP can be separated from the member approval part of the PLIP and these can be worked on independently. I'd hate to see the difficulties of a solid member approval implementation hold up the implementation of customizable member properties.
This proposal is also not risk free. Many sites have customized membership forms, which are likely to be broken by these changes. Care needs to be taken to avoid causing users undue pain.