OpenCRVS
v1.4
v1.4
  • đź‘‹Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User / role mapping
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certificate template
    • 4. Installation
      • 4.1 Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL support
      • 4.2 Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employees & roles for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure role titles
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 HTTPS & Networking
        • 4.3.3 Create a Github environment
          • 4.3.3.1 Environment secrets and variables explained
        • 4.3.4 Provision environments
          • 4.3.4.1 Building, pushing & releasing your countryconfig code
        • 4.3.5 Deploy
    • 5. Functional configuration
      • 5.1 Configure application settings
      • 5.2 Configure registration periods and fees
      • 5.3 Managing system users
    • 6. Quality assurance testing
    • 7. Go-live
      • 7.1 Pre-Deployment Checklist
    • 8. Operational Support
    • 9. Monitoring
      • 9.1 Application logs
      • 9.2 Infrastructure health
      • 9.3 Routine monitoring checklist
      • 9.4 Setting up alerts
      • 9.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Releases
      • v1.4.1: Release notes
      • v1.4.0 to v1.4.1 Migration notes
      • v1.4.0 Release notes
      • v1.3.* to v1.4.* Migration notes
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.3: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  • Organisation
  • Office
  • Create user
  • Edit user
  • Send username reminder
  • Reset user password
  • Deactivate
  1. Product Specifications
  2. Admin functions

21. User management

OpenCRVS offers an intuitive and user-friendly interfaces to efficiently administer and control user access and roles. Supporting administrators to create, edit, and manage user profiles, and provides a suite of tools for maintaining security and system integrity. This includes functions like password resets, username reminders, and user deactivation/reactivation.

Outlined below are main features to support system administrators in their role:

Organisation

Accessible from the side navigation for all users, excluding Field Agents, the Organisation view facilitates seamless navigation through the administrative structure of the user's country. This feature serves as a user-friendly tool for locating specific administrative locations, such as the Registration Office within a particular district, making the exploration of administrative hierarchies efficient and straightforward.

Office

Accessible via the side navigation for all users, with the exception of Field Agents and Performance Managers, the Office view displays a list of users assigned to a specific Registration Office, including their respective roles and statuses. Clicking on a user's name redirects to the User Audit page. Furthermore, System Administrators have the ability to perform certain actions from this view, which are detailed in the sections below.

Create user

From the Office team view, both Local and National System Admins have the capability to create a new user account. The required details for creating a new user include:

  • First name(s)

  • Last name

  • Phone number

  • Email address

  • National Identification Number (NID)

  • Role

  • Digital signature (only if the new user’s role is a Registrar or National Registrar)

  • Device

Upon confirmation, the newly created user receives login instructions, including their username and a temporary password, via SMS or email based on the system's configuration. For a detailed understanding of the process for a new user logging into OpenCRVS for the first time, please refer to the Onboarding section.

Usernames are generated automatically, based on the user's first name(s) and last name. For example, a user named Jane Smith would have the username: j.smith.

The creation of a new user is diligently logged and securely stored in User Audit.

Edit user

From the Office view or User Audit view, both Local and National System Admins have the ability to modify user details. They can do this by locating the user, clicking on the submenu button (represented by three dots), and selecting the “Edit user” option. The editable details encompass:

  • Assigned office

  • First name(s)

  • Last name

  • Phone number

  • Email address

  • National Identification Number (NID)

  • Role

  • Digital signature (applicable only if the user’s role is a Registrar or National Registrar)

  • Device

Every modification is meticulously logged and securely stored in User Audit.

Send username reminder

Users have the option to request a reminder for their username independently. However, if they encounter difficulties, assistance is available from a Local or National System Admin. Administrators can locate the user in the system and select the "Send username reminder" option from the menu. Based on the system's configuration, the user will then receive an SMS or an email containing their username.

All instance of a username reminder being sent is logged and stored in User Audit.

Reset user password

Users have the ability to reset their own passwords. However, if they encounter difficulties, a Local or National System Admin can assist. The administrator can locate the user in the system and select the “Reset password” option from the menu. Depending on the system configuration, this action will trigger an SMS or an email containing a temporary password, which enables the user to undergo the onboarding steps once again.

All instances of password resets are diligently logged and stored in User Audit. This provides a clear record of all password alterations and ensures the system's ongoing integrity.

Deactivate

User access can be effectively managed by deactivation. This functionality is available to both Local and National System Administrators. They can locate the user in the system and select the “Deactivate” option from the user menu.

Upon selecting this option, the administrator is prompted to record a reason for deactivation:

  • No longer an employee

  • Being investigated due to suspicious activity on their account

  • Other (please provide a reason in the comments)

Administrators can also add any additional comments for clarity. Upon confirmation, the user's access is revoked, making the system inaccessible to them. However, if circumstances change, a deactivated user can be reactivated by a Local or National System Admin.

For auditing purposes, a log is generated whenever a user is deactivated. This audit trail is stored in User Audit, providing a transparent record of all user access changes

PreviousAdmin functionsNext22. Comms management

Last updated 1 year ago