DHIS Connector Module - User Access Controlling

Continuing the discussion from GSoC 2021: Improving Functionalities of DHIS Connector Module - Project Updates:

As a part of the GSoC project “Improving Functionalities of DHIS Connector Module”, we are going to add a Role/Privilege based access control system for the DHIS Connector module. I’ll use this new thread for the updates of this section of the GSoC project.

I found some tutorials for adding privileges and roles to the module. https://wiki.openmrs.org/display/docs/Module+Privileges+and+Roles

https://wiki.openmrs.org/pages/viewpage.action?pageId=20381784

3 Likes

Hi @akshika47 @k.joseph,

Basically my plan is to create the privileges first, so the roles can be created later according to the user requirements. We can secure the Different pages and options in Module UI with these privileges.

So these are the privileges I suggest for the DHIS Connector module.

  1. View_Data
  2. Push_Data
  3. Manage_Metadata

Previously I thought to create a new privilege for Import/export options. But in a previous meeting @k.joseph suggested to include that too in the manage_metadata privilege

This is how the module will work for the users with/without these privileges.

Users without any privilege

  • Can’t access the module

Users with View_Data privilege

  • Can access the module
  • Have read access to these pages
    • Configure DHIS Server (Read only)
    • Location Mapping (Read only)
    • Automation (Read only)

Users with Push_Data privilege

  • Can access the module
  • Have access to these pages
    • Configure DHIS Server (Read only)
    • Location Mapping (Read only)
    • Automation
      • Can’t add/delete records
      • Can run/re-run automated mappings
    • Run Reports
      • Can push data or download ADX or JSON
    • Failed Data
      • Can push failed data

Users with Manage_Metadata privilege

  • Can access the module
  • Have access to these pages
    • Configure DHIS Server
      • Can update the connection
    • Location Mapping
      • Can edit/add mappings
    • Automation
      • Can add/delete records
      • Can’t push data
    • Create Mappings
    • Manage Mappings
    • Import/Export mappings
    • Import/Export DHIS2 API

After creating the privileges, we have to update the pages and options to display according to the user privileges. Also the backend endpoints will be updated to work according to the privileges. Then we can create roles with the combinations of these privileges.

This is the approach I thought to take. I would love to have your suggestions too. Is it ok to proceed with this or do I have to change anything?

cc: @akshika47 @k.joseph @jayasanka

1 Like

I studied the OpenMRS DHIS report module and OpenMRS DHIS integration module and I found that those modules use the followings as privileges:

DHIS Report Module:

  • View Dhisreport
  • Manage Dhisreport

DHIS Integration module:

  • Run Reports - Base privilege for running the reports
  • Manage Results - View/Send/Delete Results
  • View Server - Viewing Servers
  • Manage Server - Add/Edit/Remove Server
  • Manage DHIS Locations - Add/Edit/Remove DHIS Location Mappings
  • Manage Data Elements - Map/Edit Data Element Mappings
  • Manage Options - Map/Edit Option Mappings
  • Manage Report Templates - Manage Editing Report Templates
  • Map Cohorts - Map DHIS elements to cohorts

Seems like the privileges are created for every operation in that module.

If we use that approach, we can create privileges at an atomic level like this:

Proposed Privileges for DHIS Connector module:

  • View Connection - Viewing DHIS2 Connection
  • Manage Connection - Edit DHIS2 Connection
  • View Location Mappings - View location-orgunit mappings
  • Manage Location Mappings - Edit/Delete location-orgunit mappings
  • View Automation - View scheduled mappings
  • Run Automation - Run scheduled mappings
  • Manage Automation - Add/Edit/Delete scheduled mappings
  • Run Reports - Base privilege for running the reports
  • Run failed data - Base privilege for pushing the failed data
  • Manage Mappings - Create/Edit Mappings
  • Import and Export - Import and export mappings and DHIS2 API

We can use either this way or the one i proposed earlier.

cc: @jayasanka @akshika47

1 Like

I created an issue in JIRA for adding the module privileges.

https://issues.openmrs.org/browse/DCM-53

Please review and mark it as ready for work.

I started implementing the user access control system in the location mapping UI.
Issue Link | Draft PR Link

There are 2 privileges related to Location Mapping UI.

  1. View Location Mappings
  2. Manage Location Mappings

I used <openmrs:require > tag and <onpenmrs:hasPrivilege> tag to load content according to the privileges.

This is how the UI will work after adding the module privileges.

  • Users with Manage Location Mappings privilege (or both privileges) can edit or update mappings

  • Users with View Location Mappings privilege can only see the mappings

  • Users who don’t have any of these 2 privileges can’t see the page or the link in the navbar.
    Will be redirected to the login page if the user try to access by using the URL

cc: @jayasanka @akshika47

1 Like

Hi! I have sent a pull request with this feature. Could you please review and merge it. @jayasanka @akshika47

(There are some indentation changes, so it may be easier to review with ‘hide whitespace’ option enabled. | DCM-56: Add user privileges to Location Mapping UI by Piumal1999 · Pull Request #47 · openmrs/openmrs-module-dhisconnector · GitHub)

1 Like

Well done @piumal1999

I have also updated these 3 pages.

  1. Automation
  2. Run Reports
  3. Failed Data

Automation UI

There are 3 privileges related to Automation UI.

  1. View Automation
  2. Manage Automation
  3. Run Automation

This is how the UI will work after adding the module privileges.

  • Users with View Automation privilege can only see the automated mappings. Also the automation toggle is visible.

  • Users with Run Automation privilege can see the mappings. And also can run or rerun the mappings. (But the user should have Manage Global Properties in order to run/rerun)

  • Users with Manage Automation privilege can see the mappings. And also can add new mappings to automation and toggle the automation. (But the user should have Manage Global Properties in order to run/rerun or toggle automation)

  • Users with Manage Automation and Run Automation privileges or all 3 privileges have full access to the Automation

  • Users who doesn’t have any of these 3 privileges can’t access or see the link in the navbar

Run Reports UI

There are 1 privilege related to Run Reports UI.

  1. Run Reports
  • Users with the Run Reports privilege can run reports and push data. (User may need Get Identifier Types, Get Locations, Get Users privileges to load the locations and reports)

  • Users who doesn’t have the privileges can’t access or see the link in the navbar

Failed Data UI

There are 1 privilege related to Failed Data UI.

  1. Run Failed Data
  • Users with the Run Failed Data privilege can push failed data.
  • Users who doesn’t have the privileges can’t access or see the link in the navbar

I have sent the draft Pull request for this feature.

Please review and merge.

cc: @jayasanka @akshika47

1 Like

This is good work piumal! Well done.

1 Like