User Registration

Owned by Adam Milward
Last updated: Dec 20, 2018 by James Dai (Deactivated)
5 min read

In this article the process of User Registration for a new user is described from two perspectives: the perspective of the new user, and the perspective of an administrator.

The general progression is that

  • A new user registers, but is not yet able to log in.
  • The administrator
    • configures (global) roles and (Data Model-specific) permissions for the user,
    • enables the user,
  • and then the new user is able to log in.

New User

You can visit the home page of a Metadata Exchange instance, for example: https://test.metadata.works

And click on sign up to register.

Then enter your chosen username, email and password (please enter a password >8 characters with a set of special characters).

You'll then receive a message asking you to validate your email address.

Once you've validated your email address you will have access to the system however, you will probably start with a blank catalogue until your administrator gives you access to specific models.

Administrator

When a new user registers, at first he/she will be "disabled", have the global roles "ROLE_USER", and not have Data Model-specific permissions.

User Details and (Global) User Roles

As an administrator, you can look at a (new) user's details and global roles by clicking the "Users" action in the "System" dropdown menu (with the cog icon) in the top-right navigation bar.

This takes you to the Spring Security Management Console, where you can search for a user by username, email, and other factors. The search result appears below, and clicking on the username will take you to a page where you can view and edit User Details and (Global) Roles.

User Details

Below is an image of the page showing User Details. This shows/allows you to edit

  • The user's username
  • The user's password (can only be edited, not viewed)
  • The user's email address
  • Whether the user is "Enabled"– by default a new user will be disabled. This means he/she will not be able to login until you enable them.
  • Whether the account is expired
  • Whether the account is locked– you can use this option to lock a user temporarily
  • Whether the user's password is expired.

(Global) Roles

Below is an image of the page showing (Global) Roles of the user. By default a new user only has role "ROLE_USER". An explanation of the roles follows.

  • ROLE_USER: every user has this role.
  • ROLE_METADATA_CURATOR: a user with this role has the ability to create a new DataModel.
  • ROLE_ADMIN & ROLE_SUPERVISOR: we currently do not distinguish between an administrator and a supervisor as separate entities. Rather they should be considered as one unit. An administrator/supervisor should have both of these roles. This gives them the ability to edit user details, see and edit all DataModels, and generally perform all actions in the system.
  • ROLE_REGISTERED & ROLE_STACKTRACE: we do not use these roles currently.

Data Model-Specific Permissions

A user may have Data Model-specific permissions.

For instance, a user may be able to view Data Model A but not edit it, while he/she may be able to view AND edit Data Model B.

To set Data Model-Specific Permissions, click on the "Data Model ACL By User" action in the System menu.

This leads you to an index of users. Use Ctrl-F to find the one you want.

Selecting e.g. "Alice", you will come to a page like so. In this case, there are no entries as the user "Alice" has just been created.

There are two selection boxes: One to select a DataModel, the second to select what permission for that DataModel to grant to the user.

Selecting a DataModel:

Selecting a permission:

Click "Grant":



The entry appears. You can then delete the entry by clicking the "Delete" button.





Recursive Granting

A new feature being developed is the ability to grant permissions to a model AND its imported models.

With this feature the user may select one of three options of how to grant a permission for a model.

  1. Grant selected permission for selected model and 'read' permission for its imported models. This is recursive so it also grants 'read' for the imported models' imported models, and so on.
  2. Grant selected permission only for selected model.
  3. Grant selected permission for selected model and (the same permission) for its imported models. Recursive.

For example, granting "Administration" permission to Cancer Model v3.2.3 also gave "Read" access to all of its imported models.