Ticket #9310 (closed PLIP: fixed)

Opened 7 years ago

Last modified 6 years ago

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

+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.

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

  • Cc plip-advisories@… added

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

  1. Flexible member schema: +1
  2. 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:16 Changed 7 years ago by dokter

  • Description modified (diff)

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:19 Changed 7 years ago by esteele

  • Owner set to dokter

comment:20 Changed 7 years ago by dokter

  • Status changed from new to assigned

comment:21 Changed 7 years ago by dokter

  • Description modified (diff)

comment:22 Changed 7 years ago by khink

(In [28069]) Create a branch of CMFPlone for work on PLIP #9310. refs #9310

comment:23 Changed 7 years ago by khink

(In [28070]) Added plip config for #9310, refs #9310

comment:24 Changed 7 years ago by khink

(In [28072]) refs #9310: PLIP work on plone.app.user for flexible member registration

comment:25 Changed 7 years ago by dokter

(In [28073]) Added plone.app.users to source for this config refs #9310

comment:26 Changed 7 years ago by dokter

(In [28081]) Added configlet for registration refs #9310

comment:27 Changed 7 years ago by dokter

(In [28083]) Added registration configlet refs #9310

comment:28 Changed 7 years ago by khink

(In [28271]) refs #9310: Creating a branch for plip 9310, which requires plone.app.controlpanel to have a 'utils' module

comment:29 Changed 7 years ago by khink

(In [28272]) refs #9310: backport init (PloneMessageFactory) and utils from trunk

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:31 Changed 7 years ago by dokter

  • Description modified (diff)

Ready for review.

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

Replying to rossp:

Review added in r29614, doesn't work for me, hope it can be fixed but -1 until it can be

The FWT would really like to include this PLIP in Plone 4.0 and it looks like the work is very doable. Have you had a chance to read the review? How about addressing the feedback?

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

(In [30254]) Restore the default join_form fields to the existing fields and order. Refs #9310.

comment:43 Changed 6 years ago by rossp

With r30254 I've fixed the last of my remaining concerns. I also removed the fieldset box in r30253.

FWT vote: +1 for merge

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.

Note: See TracTickets for help on using tickets.