User Management
- Sam Im (Deactivated)
- Mary Jo Kochendorfer (Deactivated)
Owned by Sam Im (Deactivated)
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
- Scope: This feature includes stories on:
Background
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.
Assumptions
- 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.
User Stories
| # | 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:
| Must have |
|
| 2 | Create password | As an administrator I need to create passwords for users so that they can access the system. Acceptance Criteria:
| 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:
| Must have |
|
| 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:
| Must have |
|
Diagrams
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
Open Questions
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. |
Not Doing
- 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.
OpenLMIS: the global initiative for powerful LMIS software