Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Responsible team member
Current Team Member
Status
Targeted release Date
Scoping Complete Date
Jira Issue
LOE
Priority


Responsible Person:
Other parties to review/input:
FYI:
Targeted release date:

Overview

OpenSRP team assignment happens in OpenMRS. OpenMRS has an independent user, location and team management system that we use for role based access controls in Reveal. Team assignment is used to identify which operational areas and plans the user should have access to. If a user is part of a team, they can see locations that that team has access to and they can collect information against the plans that have that jurisdiction assigned to them. So, if a user is assigned to the Tha Luang Village Team, which has been assigned to 3 of the 5 operational areas within that village, they will be able to see the three operational areas and all active plans that are assigned to those three operational areas as well.

End-to-End First Time Setup Steps:

  • Create all locations in OpenMRS
  • Create all teams in OpenMRS (We need to determine the appropriate level)
  • Copy the team UUID to the OpenMRS location attribute labeled "team_id"
  • Create a user in OpenMRS
  • Assign that user to the team

Regular Admin Tasks:

  • Reassign users to different teams within the team management module so they can work in different geographic areas
  • Archive users that are in teams in the team management module so they don't have access to those operational areas anymore
  • Create new users and add them to a team
  • Move teams from one location to the next by changing the OpenMRS location properties so we can move teams around

OpenMRS Team and Location Example

Below is a worked out example of structuring the locations and teams in OpenMRS.

Below is a sample hierarchy in OpenMRS. We will focus on the Two Two Too Release Village which has 5 operational areas (Link)

 

Below is a sample team for the Two Two Two Release Village. The team is assigned to the Two Two Two Release Village in the team management module. (Link)

Below is the list of team members assigned to that team (Link)

Below is the Two Two Two Release Village OpenMRS location (Link)

Below is one of the operational areas within that village TwoTwoTwo_01 (Link)

Note that you can see the UUID of the team in the team_id field. We need to maintain these on all operational areas.

We can access all of this information through the OpenMRS API, which is documented elsewhere on the wiki.

Overarching Questions

We need to figure out a number of things as part of this specification. This section defines some of those overarching questions that lead to the eventual design of the solution.

  1. At which geographic level should we assign teams?
    1. Currently we assign them at the operational area level in locations
    2. We assign teams at the village level in the team management module
    3. What's the difference here?
  2. Are there plan-type specific requirements for assigning teams (FI vs IRS vs ?)
  3. Can we assign multiple Teams to a single Jurisdiction? (OA, FA, Spray Area)

Notes

  • Summary: Need to assign users/teams to geographic hierarchies, define user addition/deletion, and define permissions as appropriate.

Requirements

  1. Location/administrative hierarchy units must be defined.
  2. Users and user names / passwords must be defined.
  3. A team hierarchy structure must be defined (i.e. team leader, team member) if appropriate
    1. QUESTION: Does Thailand want a flat team/user structure or something more hierarchical?
  4. User permissions must be defined if appropriate
    1. QUESTION: Do all team members have access to all parts of the FI planning module, web dashboards, and mobile client?
      1. Craig Answered 7 Aug: Currently, the answer is no. We separate the web users access controls from the mobile client.
    2. QUESTION: Can all users access all geographic administrative units? Or are they restricted to a specific OU and below?
      1. Craig Answered 7 Aug: They are restricted to the location of the team where they are assigned
  5. User loading into Reveal must be defined - currently this comes from the BIOPHICS holding tables (Pierre Dane looking into this)
  6. Users must be mapped into teams and assigned operational areas/operational areas assigned to teams - see Thailand Team/User Mapping

  7. Users and teams must be added to OpenMRS and then linked to their locations

    1. QUESTION: Is this the ideal way to do this?
      1. Craig Answered 7 Aug: No, but it's what we currently have in place
    2. QUESTION: How are users/teams deleted?
      1. Craig Answered 7 Aug:
        1. Users can be archived in the OpenMRS UI
        2. User Team Association can be voided in the OpenMRS UI
        3. Teams can be voided in the OpenMRS UI 

Examples


Views

We anticipate the following views to be impacted on with the creation of this feature:

Mock-ups


Software Requirements Specification

This section contains notes on what needs to be developed that were generated 23rd July to support estimating:

Justification

Need to be able to add users to the system and do so within a given hierarchy for permission-level setting and appropriate task flow.

Dependencies

  • User names and passwords are currently in BIOPHICS holding tables 
  • QUESTION: Will this need to be updated from the BIOPHICS side? What input format is needed for new usernames & passwords for integration between Reveal and BIOPHICS?

Questions

  • No labels