View Source

Goals

The goal of this requirements page is to document the feature of User Management and the associated user stories. User Management is defined as enabling the administrator to create and manage users so that new or existing users can perform normal job duties once the setup and management is complete.
- Scope: This feature includes stories on:
  - Creating a new user.
  - Resetting a password from the user list.
  - Enhancing the usability of the user search functionality from version 2.0

In Mozambique with ESMS/SIGLUS, there is a field and logic for indicating if a user web or mobile. For now, this is out of scope.

We will use the predefined facilities, roles, programs, supervisory nodes, and rights that exist in 3.0 to complete development for this feature.
We will reuse 2.0 UI screens with minor updates to enhance data entry flow.
The existing 3.0 schema supports User Management UI data elements.
The "system" referenced is OpenLMIS.

#	Title	User Story	Importance	Notes
1	Create user	As an administrator I need to enter users into the system so that I can complete the assignment of the required roles, facilities, and programs to each user. Acceptance Criteria: Admin can create and save a new user. Validation (minimal needed) for each field that is assigned.	Must have	2.0 Design provides a dropdown/preselected list.
2	Create password	As an administrator I need to create passwords for users so that they can access the system. Acceptance Criteria: Admin creates password and manually notifies user. Admin creates User and system sends email with set password link.	Must have
3	Edit user information	As an administrator I need to edit user's details so that I can update the system to reflect changes. Acceptance Criteria: User search provides a list of available users to edit. Admin can edit user details (Username, email, firstname, lastname, loginrestricted). Validation (minimal needed) for each field is completed after it has been edited.	Must have	2.0 Design shows dialog box to enter name for search but a list is preferred.
4	Email Password reset	As an administrator I need to reset a user's password so that I can support a user's access. Acceptance Criteria: Administrator has ability to select user and send an email that resets their existing password	Must have	This is utilized when the user has access to their email address but forgot their password.

Happy Path

New user is created by Admin. User has email information included → receives email to set up password → user is sucessful in setting up password.
Admin resets a password manually → Admin searches user → Admin updates password → if an email address exists, email confirmation sent to user. If no email, no confirmation is sent.
Admin updates user details (not password) → Admin searches user → Admin updates information → Saves

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome
What does the Restrict Login functionality in the user creation process do?	Understand how frequently this is used to determine which screen should include this radio button.
What are the user fields that don't change once they've been entered?	Identify the fields that are grayed out after initial entry.
What are the validation requirements for the user assignments?	Details validation scenarios when assigning program, roles, and facilities to a user.

Mobile user identification when a user is set up. In 2.0 the administrator identifies a user as mobile to allow user creation without an email address.
Configuration screens for .csv upload to create initial facilities.
Allocation Program based rights and Admin Reports rights will be in a future release.
New Supervisory Node creation.
Creation and editing of roles will be in a future release.
Reporting updates will be in a future release.
Roles and Facilities management are separate features.
Offline functionality and saving is out of scope. Admin user must have internet access to complete any of these tasks.