Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Current »

Design

How it works

Sign up page composition

  • Title of the page : “Sign up”

  • Introductory text : “

  • Sign up Form

Sign up form composition

  • Firstname field*

  • Lastname field *

  • Email field *

    • Plus a tooltip : “Your email will not be shared”

  • Password Field *

    • Plus a tooltip a tooltip : “At least 8 characters, including 1 number, 1 capital letter and 1 punctuation mark.”

  • Company

  • Terms of use Checkbox*

  • Sign up button

  • I already have an account link that redirect user to the login page

*Mandatory fields

Sign up process

When users clicks on the sign up button after filling the sign up form :

  • A confirmation message display

  • The user for whom the sign up request was made receives an email informing him that he must validate his email address to confirm his account creation request. At this stage the user is not visible in the list of users to be approved by administrators in the backoffice.

  • As soon as the user confirmed his email, the pending account display in administrators’s dashboards in the backoffice.

  • A confirmation email is sent to the user to let him know his account request is pending validation.

  • Administrators can approve the account or not.

  • As soon as the account is approved by an administrator, the user's account becomes active, and the user receives a confirmation by email.

Content Picker

Sign up button is not displayed on content pickers’s login page.

Advanced Configuration

The registration form is automatically generated based on the REST resource for storing account requests.

Adapting the registration form structure

As a default, the REST resource is /data/userregistration which targets the structure userregistration.

You can change the target resource by overriding the default value in config entry $.register.targetPath.

Adding fields to the registration form is done by changing the structure (don’t forget tags that must be added to fields). Please note that the rest_api_include tag don’t need to be added on the structure as it has been explicitly registered in restful services.

Enrich automatically generated form

Based on the structure configuration, the form fields will automatically honour the structure properties description: type, label, compulsoriness, max-length. You can still enrich this default configuration by adding config in portal to fine tune the registration form.

Adding properties to fields description for the targeted structure can be done in $.edit.<targetstructure>.fields

For instance, the default email property in the base configuration is defined as follow:

{
  default: {
    "validators": {
      "email": null,
    },
    "description": {
      "tip-i18n": "signin.loginForm.mail.description"
    }
  }
}

Such configuration will apply a validation rule to the field to check that the value is a valid email address and add a description below the field corresponding to the tip-i18n key.

Disable the accept terms of use

You can deactivate (not show) the “I accept terms of use” checkbox by setting $.register.displayCGU to false

Translations i18n Keys

  • I already have an account link : signup.signupForm.cancelButton (i18n)

  • Sign up button : signup.signupForm.inscriptionButton (i18n)

  • Sign up title : page.title.signup(i18n)

  • Introductory text : signup.description(i18n)

Migration from a pre-2022.1

The issue :

The process of creating a new user has been revised in 2022.1 sends to new users an email asking them to validate their account.

When the user clicks on the button to validate their account the /verify action ends in error 500 with the following exception:

LOGGER:applicatif
 Class: java.lang.RuntimeException Msg: java.lang.RuntimeException: noheto.BusinessException: You do not have the right to create an authority of this object: user.
 source: website
 remoteaddr: 52.47.89.117
 uri: /api/packaged/register/verify/pX1sSnSb31qaQF1w1CC3pnNGALmkdCAjtF7-tt67ieRJTnDS8SJGSyfimxdsmP4jecoPTM6ue6A
 referer: -
 user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0
 
-------------
Throwable information:
Class: java.lang.RuntimeException Msg: java.lang.RuntimeException: noheto.BusinessException: You do not have the right to create an authority of this object: user.
 noheto.workflow.standard.Workflow.doAction(Workflow.java:346)
 noheto.workflow.standard.Workflow.execute(Workflow.java:231)
 wsnoheto.engine.ObjectWritable.processWorkflowAction(ObjectWritable.java:3518)
 wsnoheto.engine.ObjectWritable.processWorkflowAction(ObjectWritable.java:3472)

Explanation : when the systems sends an email to validate the email address, the link that is provided executes an action on the temporary USERREGISTRATION account: it executes the workflow action defined in the validate_email_workflow_action plugin parameter which has the default value validate.

In previous versions, the validate action was creating a user, and when the application is correctly secured, a non connected surfer is not allowed to create a user.

The purpose of the action should be to validate the email address entered and thus allow the administrators to approve the creation of the final account.

How to solve :

  1. Create a new step in the workflow of the userregistration object: unverified email

  2. Add a verify action from unverified email to inactive

  3. Inactive status must be published true

  4. Change the default status of userregistration to have the ID of unverified email

  5. Change the activated value of userregistration to 2

  6. Set the validate_email_workflow_action of the PACKAGED_RegistrationEmails to verify

In starter-kit, we have chosen not to go through the workflow to approve the creation of an account: by going through the workflow, it is not possible to send the user back to the account finally created. So we have a button that appears in the toolbar if enable_create_account_from_request is set to true. To keep your existing operation, you'll have to set this parameter to false (to not have the button)

Some notes:

  • By creating a new status and setting the default value of status, non-validated accounts created before the update can still be approved even if they haven't validated their email address (as before). The following ones on the other hand will have to go through this address.

  • You will have to customize the email template, but... it's documented → https://crossmedia.atlassian.net/wiki/spaces/WD/pages/2160427009/UI+configuration+checklist#Registration-related

  • Depending on how the account creation trigger is written (validate in your workflow), you may be able to name the action that changes from unverified email to inactive validate → advantage, no need to change the default value of validate_email_workflow_action (a rather limited advantage, I agree)

  • you can prevent admins to see userregistration with unverified email status → avoid creating accounts with unvalidated email

  • No labels