Talk:UC AWOB UM 01 Register User

MPDL,GAVO

An individual wants to register to AWOB. It means that an individual wants to create an account in an awob system. It doesn't mean that it requests to become a member of a project.

Status/Schedule

 * Status: Specification
 * Schedule:Demonstrator

Triggers

 * A person wants to create an account in an awob system.

Actors
For actor definitions see AWOB concepts Actor
 * Applicant
 * a person who applies for an account in an awob system.
 * The person may or may not have an account in awob.

--Rupert 10:31, 20 June 2011 (CEST) At lease three roles would be necessary to start with: 'Project Initiator', 'Registered AWOB User' and 'Unregistered User' ('AWOB Admin' may not need to be described yet?). Another page may describe the Roles (how does a 'Unregistered User' becomes a PI).


 * we shall only use one name of an actor in this particular place. User registration use case is only valid for "prospective AWOB users". These are persons who'd like to become an AWOB user. Already now we have "Applicant" and "individual". Proposal: use "Unregistered User" as Rupert suggests. It would be good (if we already want to maintain AWOB Concepts Actor page) to link the "Unregistered User" to a particular heading in that page e.g.

Unregistered User

--Natasa 17:26, 20 June 2011 (CEST)

--Jaiwon A person can request an account in awob initiated by one's own will, or by invitation of a project PI. Therefore, one cannot assume that it is always triggered by an invitation which requires other actors like project PI. When a person applies for an awob account the system cannot assume that it has no awob account, yet or whether it may or may not be qualified to get an awob account. So I think that neither 'prospective awob user' nor 'unregistered user' is a right term. I called the actor 'applicant' in order to not to make any of there assumptions. To be a successful applicant it must be an 'individual'.

Pre-Conditions

 * an successful applicant must be an Individual where successful means that the applicant is qualified to get an awob account..

--Rupert 10:33, 20 June 2011 (CEST) One role Project Member (applicant) exists and can be assigned to any registered person.
 * do not understand the Project Member role above for user registration - did you mean "default user role"? :) . Would define the following precondition: Unregistered User must have an email address --Natasa 17:33, 20 June 2011 (CEST)

--Jaiwon If an applicant's request is accepted by the awob system the applicant becomes a 'registered awob user(RU)' as specified in Post-Conditions. No project role is granted to the applicant by the system. A project role is assigned only if a registered user become a member of a project.

Flow of Events
An applicant
 * 1. opens up awob registration page.
 * 2. fills up 'registration form' (username, password, email address, affiliation(?)).
 * 3. submit the form data.

The system
 * 4. check if all the mandatory fields are provided.
 * 4.1 if true go to 5.
 * 4.2 othewise display error messages on the regitration page. go to step 2.
 * 5. validate the form data whether email address, username(?) are unique in the system.
 * 5.1 if valid create an inactive registered user
 * 5.2 otherwise display error message on the regitration page. go to step 2.
 * 6. send an email with a confirmation(or verification) link to the applicant.


 * 7. The applicant confirms/verifies it.

The system
 * 8. Activate the registered user.
 * 9. Send a confirmation email to the activated registered user.

--Rupert 10:37, 20 June 2011 (CEST) Not sure if the confirmation mail should fire first and then activation is done by a link from that mail.


 * 10. End of the story

--Natasa 18:02, 20 June 2011 (CEST)I'd like to suggest splitting this use case in 3 use cases e.g.: a) register account     1 Unregistered user chooses to register as a user of AWOB      2 The system displays a registration form, requesting some basic information (username, email address, institute, password - we shall precise which)      3 Unregistered user enters necessary information and confirms his input      4. The system checks if all the mandatory fields are provided.         4.1 if all mandatory fields are provided, continue with step  5.          4.2 otherwise the System displays error messages on the registration page. Continue with step 2      5 The system checks if any of the e-mail account or username provided are already registered in AWOB        5.1 An AWOB user with same e-mail account (or username) does not exist in the system (continue with step 6)        5.2 Otherwise the system displays error message on the registration page. Continue with step 2      6. The system creates a new "inactive" AWOB user account (with exiry timestamp) and sends a confirmation request e-mail (with a predefined subject, text and link for the confirmation request)  to the provided e-mail address. 6.1. The system displays a success message. The use case ends successfully. Alternative 5.2.1. Otherwise the system displays error message on the registration page. The user cancels the registration.The use case ends unsuccessfully.

b) confirm account registration Actor    Unregistered user  Precondition    Unregistered user has an email account    Unregistered user received an e-mail with activation link for AWOB  Flow        1. Unregistered user chooses to activate her account by following the activation link    2. The system validates the activation link      2.1. if the activation link is valid, the system activates the user account and displays a success message containing further instructions. The use case ends successfully.      2.2. if the activation link is not valid, the system displays an error message and asks the user to register again. The use case ends unsuccessfully.

c)delete expired "inactive" AWOB user accounts   Actor      System    Precondition     *User account is "inactive" and expiry timestamp is earlier than the current timestamp     *User account does not have any roles or privileges or resources associated with AWOB    Flow of events     1. The system prepares a list of "inactive" user accounts whose expiry "timestamps" are earlier than the current timestamp (checkpoint timestamp)     2. The system deletes all "inactive" user accounts from the list. The use case ends successfully  Postcondition     there are no inactive user accounts with the expiry timestamp earlier than the checkpoint timestamp (used in step 1)

..

Post-Conditions / Results

 * A registered user is created with default role Registered AWOB User (RU).

Future development

 * Derive information from the applicant's email address whether the user can automatically become a "Project Creator".