Use Cases - UC-06 Users

• User must be logged
• User must have ROLE_ADMINISTRATIVE

1. User requests to obtain a user entity by primary key.
2. System returns user model.
3. User updates general information. Stats fields cannot be modified (failed tries, and blocks).
4. User may change the associated customer taking some considerations:
   1. A user may have multiple roles but ROLE_USER cannot mixed with any other role.
   2. Only users with ROLE_USER can be linked to a customer (so removing that role implies removing current linkage).
   3. Users with ROLE_USER must have an associated customer (so adding this role implies a mandatory customer linkage).
5. System may offer the option to update the users associated to customer (@see UC-06b UserManagement-updateUser)
6. System may offer the option to update the products licensed to current customer (@see UC-07b LicenseManagement-updateProductLicense)
7. System save customer information.

System will raise and exception if primarey key does not exist.

• User must be logged
• User must have ROLE_ADMINISTRATIVE

1. User request to remove a user.
2. System will check for associated customers restrictions and warn the user about to:
   
   1. If  candidate user to be removed is the customer contact person system will warn to select another contact first.
   2. If customer only has one associated users, it cannot be removed.
3. User accepts to remove the user.
4. System removes the user.

System will raise and exception if primary key does not exist.

System will raise and exception if customer restrictions are not being satisfied.

• User must be logged
• User could have ROLE_ADMINISTRATIVE or ROLE_PRODUCT_MANAGER

1. User request for a list of users.
2. System will query database using provided parameters
3. System will return the result list.

None

• User must be logged
• User must have ROLE_ADMINISTRATIVE

1. User requests to unblock a blocked users by number of failed logins exceeded from users list.
2. System will update user.
3. System will return to the users list.

System will raise and exception if primary key does not exist.

• Users with role ROLE_ADMINISTRATIVE may reset passwords from other users

1. User requests to reset a password
   1. If role is ANONYMOUS (not logged)
      1. System returns recovery form.
      2. Users sends current username or email
      3. System generates a new password and it will send the new password to the provided email y username and email matches
   2. If role is ROLE_ADMINISTRATIVE_USER
      1. System returns recovery form for selected user
      2. Admin User sets new user password.
      3. System sends the new password to the user email.(no validation performed)
   3. Other logged users
      1. System returns recovery form
      2. User sets the new password and the old current password.
      3. System changes the password and notifies user y current password matches.

System will raise and exception if primary key does not exist.

1. User requests to sign in
2. System returns login form
3. User sets username and password
4. System validates credentials and check user block status
   1. If user is blocked system will be warned about and credentials will be ignored. 
   2. If the credentials match then user is redirected inside the portal. 
   3. If the credentials did not match user will be warned about that invalid credentials.
      System may track that invalid login attemp over that username. If max login attemps is reached user account must be blocked.

System will raise and exception if user is blocked

System will raise and exception if user credentials are wrong