Custom Registration Workflow

We now have a workable Register plugin supporting the simplest "friends" workflows. We now consider how we might handle more nuanced situations without stumbling as we have in past proposals.

See Registration Workflows from five years ago.

See Landing Page Registration from three years ago.

See About Register Plugin in limited use today.

# Responsibilities

We consider the case where a community leader supports new members by providing a welcoming registration form, and where a service operator complements this workflow with validated actions provisioning new sites for the expected new members.

● Community leader provides a custom home page form.

The leader can upload index.html that prompts a new member for qualifying information and post that to a new Register server-side plugin endpoint for custom provisioning from the community's root wiki domain.

● Service operator provides custom site provisioning.

The service operator installs custom register.js module in the private status directory associated with the community's root wiki domain.

The existing Register server-side plugin installs the specialized register.js module upon startup and delegates to this dynamically loaded module for further validation and provisioning of new sites. github

# Variations

Managing "registration codes".

Provisioning with "starter pages".

# Example

We design an html custom home page that requests visitors sign up for later announcements. github

The Crazy Wiki Place

We're not taking new members yet. Stay tuned.

The ok button POSTs the entered field information to the /plugins/register/custom endpoint. This in turn invokes the post(data) function of the custom status/register.js module which writes the data to an append-only asset to be processed by the community leader when convenient.

The community leader can fine tune the messaging or field validation by uploading a revised home page html script should signups not meet expectation.

Only the service operator has credentials for updating the status/register.js module since the operator is ultimately responsible for service integrity. The operator and leader must cooperate on the specification and implementation of this component. The module can import and operate via the node fs api. node

# Catalog

We envision a catalog of registration workflows where on a single page the purpose and experience of a particular workflow accumulates along with sample assets for index.html and corresponding register.js modules will be archived.

We imagine some workflows will require additional configuration by policy makers and supervisors. This could include private data, codes, and organizational details to be stored in the server along with and for the use of status/register.js module. The catalog page could provide additional specification, documentation and possibly operational html scripts supporting smooth deployment in practice.