Location Based Access Control Project Proposal Discussions - GSoC 2018

[gayanw]

Project: Location Based Access Control

Primary mentor: @dkayiwa

---

I have given some thought to the matter, as I’m interested in this project. And here is what I think. Your suggestions, and corrections are most welcomed.

By location, we’re actually referring to the session location of the currently logged in user. To my understanding user can belong to more than one location.

Filtering in the API backend

Say a user have access to both ‘Inpatient Ward’ and the ‘Outpatient Clinic’, and is not a ‘System Developer’, he/she should be able to retrieve only the resources (patient, encounter) that belongs in the same locations; ‘Inpatient Ward’ and the ‘Outpatient Clinic’.

We can include an additional ‘location’ query parameter for GET /encounter, /observation, and /patient. It is useful in case the logged in user is a ‘System Developer’, or in case that he/she belongs to more than one location, but want to filter out resources from a certain location.

Filtering in the UI : REFERENCE application

Say a user have access to both ‘Inpatient Ward" and the ‘Outpatient Clinic’. Even if he belongs to both locations, if in the reference applications’ session location (dropdown beside the username) is set to 'Inpatient Ward", only the resources that belongs to ‘Inpatient Ward’ should be shown in the UI.

Extra:

• When registering a new user/patient, we can default his/her location to the session location of the currently logged in user.
• In the ref-app logged in user (unless a System Developer) should see only the locations that he/she have access to.

Following is quoted from the Wiki page:

Some implementations want to register users and patients in certain locations. Then access them based on the location that some one has logged in. That way, if some one is logged in a certain location, they should see only those encounters, observations, and patients registered in that location. But the System Developer account should be able to see patients in all locations.

Objectives

• Assign users to locations on registration
• Assign patients to locations on registration
• During encounter, observation, and patient searches, return only those in the logged in location
• Ability to move patients from one location to another by an administrator
• Ability to assign locations to already existing patients
• Ability to assign locations to already existing users
• Login screen should not require users to select locations because on login, you know the location in which a user belongs.

[suthagar23 (Suthagar Kailayapathy)]

Hi, everyone!

I am Suthagar, final year undergraduate at the University of Moratuwa. I am involving with OpenMRS for more than a year and worked with several tasks from the beginning. I have completed my GSoC at OpenMRS last year and I would like to work on this project this year too

Thanks a lot @gayanw for the brief introduction to the project here. I have added more information to get understanding about this project.

---

So far, Reference application only kept the location information inside the session and the user can simply change their location through the location drop-down or use appui/session REST service. Now the time to restrict the OpenMRS Ref app users by their registered locations.

Some of my thoughts and ideas for this project are given below,

1. This is the time to reduce the user login requirements .

   When we log in to the Ref App, User needs to enter the username, password, and need to select the location to enter the application. By this implementation, User will not be required to select the location while they logging in. Because the default location has been set to the user at the user registration and it will be fetched from the context while they log in.

   

2. Assign locations to the users and patients on the registration

   Currently, OpenMRS Ref app does not offer the location selection field during the registration process. So there should be a location selection field on the user registration and patient registration dashboard to select the default location for them. It can be continued in this ways,

   • Current login user location will be added automatically to the patient or new user location field.
   • The person who registers the patients or new users, can change the location or can add one or more locations for them.

3. Encounter, observation, and patient searches return only those in the logged in location

   We can fetch the encounter, observation, patient information through ref application dashboards or REST Webservices. It will provide widely data from all locations for the query. After this project, Those dashboards and REST Web services should only serve the data which belong to that logged in location(or locations). It will not expose the other encounter, observation, and patient information which belongs to other locations.

4. How to change the user default locations?

   OpenMRS users can be assigned to one or more locations for them and they can use the location drop down to switch between their assigned locations (The drop-down menu will only contain the assigned locations information). But if the user wants to get access to other locations There can be some ideas to process this task,

   • If the user is SysAdministrator then he can assign his self to the required locations/ remove the assigned locations.
   • If the user is not a SysAdministratior, then he needs to request the SysAdminstrator to approve the location changes (If the user hasn’t location change privilege and free location selection setting is OFF in the system).
   • If the current user has the location change privilege, then he can easily change the locations without SysAdministrator approvals (new privilege needed).
   • If the given Ref App setting is open to free location selections, then users can add/remove their locations without the SysAdminstrator approvals (new setting needed)

5. How to change the Patient default locations?

   OpenMRS patients can be assigned to one or more locations during the registration process. But they may need to change the default location or locations after the registration process. So It can be done using the following ideas,

   • If the logged in user is SysAdminstrator, then he can simply change the patient locations.
   • If the user is not a SysAdministratior, then he needs to request the SysAdminstrator to approve the location changes (If the user hasn’t location change privilege and free location selection setting is OFF in the system).
   • If the current user has the location change privilege, then he can easily change the patient locations without SysAdministrator approvals (new privilege needed).
   • If the given Ref App setting is open to free location selections, then users can add/remove the patient locations without the SysAdminstrator approvals (new setting needed)

6. How to assign the locations to the existing users and patients?

   This will be a cool new feature for the registration purpose. But how can apply this changes to the existing registered users and patients in the Ref applications? There can be some ideas to overcome this issue,

   • User or patient locations can be assigned through the user profile edit feature or patient info edit feature for the existing persons (will decide later about the SysAdministrator approvals for this kind of workflow).
   • Bulk location change facility - Changing the existing patient locations one by one will take a long time and it will not an easy process. So ref application should have the bulk assign feature for their patients. Logged in user can select the group of patients using some filters (based on address, diseases, encounters, observation, etc), and apply the default location information to those group easily.

7. Restriction and new requirements for the REST Calls

   REST calls while in a certain location should return only those results in the logged in location. Currently, REST Service module checks the user login status before serving the required information over the web services. Now it should capable of these workflows also,

   • REST Calls for those resources can be attached to the location information (mostly location UUID). So the web services module should check the required location with the current user assigned locations. if those are matching, then Web service module will respond with the required information belongs to that location( or locations). If that does not match, there should be an exception to the location access.
   • If the REST request haven’t any location information, The response should contain only the information belongs to the registered user locations (It will help for existing implementation based on the REST web services, and will not require more changes on their side )

---

I hope, that information mentioned above will add more values to this project. We need some more ideas and suggestions from the mentors(@dkayiwa) and community to make this project better.

If you have and ideas or suggestions, please feel free to add here

CC : @dkayiwa

[samuel34 (Samuel Male)]

Hi all,
I got excited about this project idea at first glace, I personally feel negative about the current implementation of location management in openmrs .
I agree with @gayanw and @suthagar23 on the way of seeing and understanding stuff on this project. I feel you guys have given a detailed description of your understanding about this project which I feel is correct and agree with you guys I just won’t override what is required to implement this project idea.
I have also been in OpenMRS for a while, and I feel I ALSO want do some serious significant contributions to the community by partaking this project .
CC : @dkayiwa

[suthagar23 (Suthagar Kailayapathy)]

Hi @samuel34

Glad to know it from you. We hope, this project will full fill your thoughts about the OpenMRS location management . Further more, If you have any ideas or suggestions from your side, please feel free to discuss with us.

[suthagar23 (Suthagar Kailayapathy)]

Furthermore, @dkayiwa I would like to get some ideas related to this project,

1. Some users can have the access to more than one locations. So how will they switch their access to the assigned locations? Do we need the location switchers or any other ideas?

2. If the user has access to more than one locations, then How can he get all services or information for all locations without switching the locations?

[dkayiwa (Daniel Kayiwa)]

1. When they log in, they will see data from all the locations that they have access to.

2. Data is fetched as a sum from all locations that they have access to.

[suthagar23 (Suthagar Kailayapathy)]

Currently, we have location switcher to move between all locations. So If after this location-based access control implementation, Initially, the user will see the data from the locations that they have access to,

• So the locations switcher should have an item as "All accessible locations" (It will be selected after the login) - New Selection Item from the previous implementation
• The location switcher will contain other accessible location’s name below the “All accessible locations”. So the user can click one of them to get only the data related to that location.

@dkayiwa Is it okay to have in our implementation?

[dkayiwa (Daniel Kayiwa)]

@suthagar23 i like your suggestion for those who have access to more than one location. But for those 99% cases that have access to just one location, no need to show the location selection widget.

[suthagar23 (Suthagar Kailayapathy)]

@dkayiwa I agree with you.

I think Admin and other some users may have access to more than one locations. (who are in that 1% )?

• So better to check the accessible locations numbers and add this extra “All accessible locations” to the locations switcher if the user have more than one.
• If the user has access to only one location, then we can show the current location information without the switcher (no need of drop-down and drop down arrow also).

The reason behind this one is, If we are showing data from all accessible locations, then the location information should indicate the user about the currently selected location(two or more). Otherwise, We may miss the actual concept here.

Anyway, If we can simply skip this, then no need to worry about this one ?

[suthagar23 (Suthagar Kailayapathy)]

@suthagar23

How to change the user default locations?

OpenMRS users can be assigned to one or more locations for them and they can use the location drop down to switch between their assigned locations (The drop-down menu will only contain the assigned locations information). But if the user wants to get access to other locations There can be some ideas to process this task,

• If the user is SysAdministrator then he can assign his self to the required locations/ remove the assigned locations.
• If the user is not a SysAdministratior, then he needs to request the SysAdminstrator to approve the location changes (If the user hasn’t location change privilege and free location selection setting is OFF in the system).
• If the current user has the location change privilege, then he can easily change the locations without SysAdministrator approvals (new privilege needed).
• If the given Ref App setting is open to free location selections, then users can add/remove their locations without the SysAdminstrator approvals (new setting needed)

For above requirement, Could we think about some new privileges like these following?

1. ACCESS_TO_DEFAULT_LOCATION_CHAGE_VIEW - User can get the form view to change their default locations (just the form UI for the location change). It will reduce the location change approval request to the System administrator.
2. CAN_CHANGE_DEFAULT_LOCATION - User can change their locations without SysAdmin approvals.
3. ADD_ONLY_ACCESSIBLE_LOCATIONS_TO_PERSONS - User can add only current selected location as the patient default location
4. CAN_ADD_ANY_LOCATIONS_TO_PERSONS - User can add any locations to the patient default location
5. CAN_CHANGE_PERSONS_DEFAULT_LOCATIONS_VIEW - User can get the patient location change form view. It will reduce the location change approval request to the System administrator.
6. CAN_CHANGE_PERSONS_DEFAULT_LOCATIONS - User can change the patient default locations without SysAdmin approvals.
7. BULK_PERSON_CHANGE_ACCESS - User can change the default locations for a bulk of patients or selected amount of patients.

There might be some more privileges while we actually work on this project.

@dkayiwa What do you think about this privileges? These are too much for this requirement or can we move this one?

[suthagar23 (Suthagar Kailayapathy)]

Hi every one,

• Assign users to locations on registration
• Assign patients to locations on registration

Here, We need to change the workflow and the existing UI with a location input field to attach the location on registration. Along with this project description, what do you think about building an OWA for the location Management?

We can add some features like this following,

1. Location wise reports with user information and patient information
2. Quick Location Add/Change for the users and patients (apart from the normal user add/edit and patient add/edit)
3. Bulk location Add/Edit feature
4. Ability to move patients from one location to another by an administrator

---

I think We haven’t any methods to merge two or more locations into existing one or a new one. What do you think about adding a feature to merge locations ?

CC : @dkayiwa

[samuel34 (Samuel Male)]

Thanks for your good ideas in this @suthagar23

@suthagar23

Along with this project description, what do you think about building an OWA for the location Management?

But I think think this project is straight forward, it just requires building a new module against core . No need of an OWA.

@suthagar23

Location wise reports with user information and patient information

Your such a bright guy, reports should reflect location information about a Patient.

@suthagar23

Ability to move patients from one location to another by an administrator

I think this is already part of the project objectives

@suthagar23

Bulk location Add/Edit feature

Please throw more light about this feature, could be interesting

[suthagar23 (Suthagar Kailayapathy)]

Hi @samuel34

But I think think this project is straight forward, it just requires building a new module against core . No need of an OWA.

Why do you think about a new module instead of Core alteration? I thought something like this following,

We can include a location variable to the required classes(Eg : person class) to implement the location access control. Then we should modify the user registration forms and patient registration form to include the location filed. Then we can extend those feature over an Open Web App since we are moving towards the OWA side.

If we planned to go for a new module, what will happen to the existing patient and user management? those are will exist without any information related to location access control?

CC : @dkayiwa

[samuel34 (Samuel Male)]

Thanks for the good idea @suthagar23 , maybe @dkayiwa could give us a broader insight on this
But just to express my view on the OWA idea. OWA is the recommended approach dealing with the UI today, but I personally think that all these changes prior this project should be bundled in one development (module) to just just comeup with a clean development. Rather than adjusting core and again make an OWA
CC: @dkayiwa

[suthagar23 (Suthagar Kailayapathy)]

@samuel34

I personally think that all these changes prior this project should be bundled in one development (module) to just just comeup with a clean development. Rather than adjusting core and again make an OWA

Yah, We should consider this as well

@dkayiwa Could you please give an idea on this?

[dkayiwa (Daniel Kayiwa)]

One of the reasons why we want this to be in a module is because the implementations that asked for it are not yet ready to upgrade. Secondly, a module would give us an opportunity to see the real world usage before we eventually make a decision on whether this should be a core change or not. A path similar to https://issues.openmrs.org/browse/TRUNK-5015

[tendomart (tendo kiiza Martyn)]

@suthagar23 , @samuel34 why are you guys thinking of a change in Core?

[suthagar23 (Suthagar Kailayapathy)]

@dkayiwa

One of the reasons why we want this to be in a module is because the implementations that asked for it are not yet ready to upgrade. Secondly, a module would give us an opportunity to see the real world usage before we eventually make a decision on whether this should be a core change or not.

True Words @dkayiwa. I have never thought about this before .

So we can move to build a new module to support the Location Based Access Control. Let me check the TRUNK-5015 to get an Idea about this.

---

why are you guys thinking of a change in Core?

Now, I have thrown that point because of a valid reason pointed out by @dkayiwa . The idea of building a new module will give us an opportunity to see the real world usage, and then we can decide to make a direct Core change.

[suthagar23 (Suthagar Kailayapathy)]

hi @dkayiwa

I had a look into the given ticket and then I have figured out some points. But still, there are some key points which are needed to be cleared.

So now we have planned to create a module with Location-based access control. The new module should contain these following features/pages,

1. Patient Registration and User Registration forms with location input field should be included in this module
2. Login screen without location selection should be included in this module. We can map that screen to the default login screen later
3. Improved patient search screen should be included which can return only data in the logged in location
4. Page to move the patient from one location to another location should be included.
5. Page to add locations to existing users and patients should be included.

I think we can fetch some implementations from other modules like ui-framework to start the new module implementation on top that.

@dkayiwa Could you please given an idea about this work flow?