Motivation
I started down this path while trying to clean up the
BulkRegistration topic. There have been several ancient tasks opened to improve this process. I've done some of them without a feature proposal, but I'm getting to the point that the changes need some more serious thought.
Primary objective is to simplify tailoring of the Registration system. There are way too many places to touch to customize.
Description and Documentation
Current state:
Currently our user registration is anchored on the System.NewUserTemplate. This template topics points to System.UserForm which lists a large number of
possible fields that someone might want to collect either during or after registration. So to put in context:
- NewUserTemplate: Defines the default content of each new user topic. It links to:
- NewUserForm: Defines the sum total of all formfields that are eligible to be entered either during or after registration.
- For forms based registration:
- The UserRegistration form %INCLUDEs sections named as
extrafield_fieldname
So to activate OrganizationName. you include section extraField_organisationName
- Currently only OrganizationName, OrganizationURL, Country and Groups are supported in the forms. Any other fields require more work.
- For Bulk registration:
- The user would manually create the input table, including a column:
...| OrganizationName |...
And to complicate things a bit, Registration must collect WikiName. LoginName, Password and Email. Those 4 fields are required to register a user on the form. Password is optional on Bulk Registration, and Email is the only mandatory field that is also listed in the form.
The complete list of field names in UserForm is:
FirstName,LastName,OrganisationName,OrganisationURL,Profession,Country,State,Address,Location,Telephone,VoIP,InstantMessagingIM,Email,HomePage,Comment
There is also a special field 'AddToGroups', which if present, causes the registered user to be automatically added to the listed groups. This works on individual registration, and is added to BulkRegistration for Foswiki 2.2.
Finally to round out arcane crap, field names when entered in the Registration form (but not in bulk register) are encoded Fwk0[nameOfField] if optional, and Fwk1[nameOfField] if mandatory.
So as of Foswiki 2.1, to create a custom registration page for a new class of users:
- Create a new UserForm for the new fields: eg. CustomerForm
- Create a new NewUserTemplate which links to the new form. eg. NewCustomerTemplate
- Create a new UserRegistration topic, which identifies the new user template. eg. CustomerRegistration
- For new fields, add sections to UserRegistrationParts to define the HTML input fields.
All this works today for individual registration. BulkRegistration was missing the AddToGroups, and templatetopic was complete undocumented.
Bulk Registration
In order to simplify, I've created a topic
http://trunk.foswiki.org/System/BulkRegistrationInputTemplate (need admin to view), which uses a QUERY to generate the input table:
That all works fine, but it's noisy. It lists all possible fields. Most likely a lot more than needed.
Examples
Impact
Need to make sure not to break any customized registration forms.
Implementation
I'm still puzzling my way through, but I'm leaning toward changes in the "NewUserTemplate" and let that drive all the other customization
NewUserTemplate still points to UserForm (or a replacement form as desired by the installation.)
Add "settings" section to a
templateonly
section of NewUserTemplate which can be extracted to control the registration:
- %SET{"REGISTER_REQUIRED" value="OrganizationName"}%
- %SET{"REGISTER_ADDITIONAL" value="OrganizationURL,Country"}%
- ... Any other settings required by the UserRegistration page to tailor the contents
The BulkRegistrationInputTemplate would then use these two lists to generate first the required, then the optional column headings,
and the UserRegistration topic could use them to %INCLUDE sections of the registration form, prefixing Required fields with Fwk1, and optional with Fwk0.
--
Contributors: GeorgeClark - 02 Mar 2016
Discussion
And... the more I dig into this, the less hopeful it looks. The reason for the custom per-field includes is because of MAKETEXT translation of the form field labels. So a parameterized include isn't going to cut it.
--
GeorgeClark - 02 Mar 2016
Changing this to discarded ... Work done on other proposal, and this got lost / overlooked.
--
GeorgeClark - 16 Mar 2017