LBAC-3 Added implementation for assigning the patients to the locations on registration #4

suthagar23 · 2018-05-23T16:50:17Z

Description

Added implementation for assigning the users to the locations on registration.

PatientControlImpl - Contains the code base to register locations for the persons
Constants - Included some constants variables for the code usage

Ticket

Ticekt : https://issues.openmrs.org/browse/LBAC-3

Others

I was able to compile the project without any failures.

suthagar23 · 2018-05-26T02:25:36Z

@dkayiwa I have changed this PR with the whole code base for the location assignment while patients registering on the system. Please have a look at here.

dkayiwa · 2018-05-26T20:18:58Z

Have you tested this from the end user's perspective and proved that it works?

suthagar23 · 2018-05-27T02:05:57Z

Yes @dkayiwa, This implementation is enough to create a personAttribute with accessLocation value in the database.

This implementation will work as shown below,

Fetch the accessLocation personAttribute from the logged in user and assign that location to the patient.
If the logged in user doesn't have any accessLocation personAttribute(for only beginning), then it will fetch the first location from the system as default.

We can improve this to select the locations by the user for the patients, and can improve to find a default location as well.

dkayiwa · 2018-05-27T12:05:29Z

Can you list for me the steps to test this out (from the end user's perspective)?

suthagar23 · 2018-05-27T13:57:57Z

Sure,
Just clone this branch and load this module into the reference application.
Then register a new patient using patient registration form in the dashboard.
(I have disabled the logs here, so you need to check this personAttribute using the database)
Query : select * from person_attribute where person_attribute_type_id=(select * from person_attribute_type A where A.name='accessLocation')

dkayiwa · 2018-05-27T18:49:18Z

How do i specify a location, as an end user?

dkayiwa · 2018-05-27T18:54:28Z

omod/src/main/resources/config.xml

@@ -46,5 +46,10 @@
 		<file>messages_es.properties</file>
 	</messages>
 	<!-- /Internationalization -->
+
+	<advice>
+		<point>org.openmrs.api.PatientService</point>


Shouldn't this be on PersonService?

Yes correct, Actually I plan to change it to PersonService while implementing the user location management(To address Patients and Users). I addressed this PR as only for Patients, So I handle only with high-level PatientService.

I will change it to Persons and will update the PR content.

I thought PersonService would automatically deal with patients because they are persons. Not so?

Nope, AFAIK We need to access this PatientService

dkayiwa · 2018-05-27T19:00:29Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientControlImpl.java

+/**
+ * It will used to implement the AOP Methods for PatientServiceImpl class
+ */
+public class PatientControlImpl extends StaticMethodMatcherPointcutAdvisor implements Advisor {


Shouldn't this be named PersonServiceAdvisor?

I will change it to Persons and will update the PR content as I addressed above

suthagar23 · 2018-05-28T02:15:18Z

api/src/main/java/org/openmrs/module/locationbasedaccess/common/Constants.java

+
+    public static final String PATIENT_OBJ_NAME = "PATIENT";
+
+    public static final String SAVE_PATIENT_METHOD_NAME = "savePatient";


This need to be updated as saveUser to make those changes.

We have not yet got to the ticket which deals with users.

suthagar23 · 2018-05-28T02:15:49Z

api/src/main/java/org/openmrs/module/locationbasedaccess/common/Constants.java

+
+    public static final String ACCESS_LOCATION_PERSON_ATTRIBUTE_TYPE_NAME = "accessLocation";
+
+    public static final String PATIENT_OBJ_NAME = "PATIENT";


This need to be updated as USER to make those changes(To deal with PersonService).

Not handled users yet

suthagar23 · 2018-06-10T03:53:42Z

@dkayiwa Finally I came up with this PR,

If the user already customized their patient registration dashboard with the custom location selection dashboard, then It will automatically save the person attribute (No need of AOP).
If the user didn't customize their patient registration dashboard, then the default access location for the new patients will be fetched from the logged in user session location(Using AOP).

Please use this App definition to customize the patient dashboard - https://gist.github.com/suthagar23/f0b92381aec5d0ad6d70e4eb40eb308d

You need the updated appui module to run this part!

dkayiwa · 2018-06-10T09:50:27Z

You are still doing more than what i asked, for the first pass.

suthagar23 · 2018-06-12T02:17:28Z

Oh @dkayiwa

I have removed the AOP implementation from this PR. It has a simple implementation to assign the access locations through patient registration dashboard now.

Please use this App definition to customize the patient dashboard - https://gist.github.com/suthagar23/f0b92381aec5d0ad6d70e4eb40eb308d

dkayiwa · 2018-06-12T09:04:30Z

No need of any AOP to assign access locations. I think you are still complicating the use case. Let me state this again.

Person attributes are stored normally using the patient registration form which you have configured as such.
When i log in a certain location, i should only see those patients whose person attribute point to that location.

As simple as that. I do not want to see code which implements any thing apart from just that. This is a very simple use case which we can even demonstrate to the client, as concrete progress update.
Does it make sense?

suthagar23 · 2018-06-12T15:44:37Z

Yes @dkayiwa. I totally understood.

It will be a solution for the Case-1.

Then shall I create another ticket for case-2?

dkayiwa · 2018-06-12T19:37:15Z

When you ask me about use cases 2 when you are not yet even done with use case 1, i start to think that you are not prioritizing as you should.

suthagar23 · 2018-06-15T10:07:54Z

Oh, I think, you missed my point in the last comment 😁,

I have mentioned
UseCase - 1 as,
Person attributes are stored normally using the patient registration form which you have configured as such.

And Usecase-2 as,
When i log in a certain location, i should only see those patients whose person attribute point to that location

This PR will be a solution for usecase-1 and, I will work to create another PR for usecase-2. Is it alright?

dkayiwa · 2018-06-15T10:24:08Z

You pull request title "Added implementation for assigning the patients to the locations on registration" says it is assigning patients to locations. Isn't that supposed to be automatically done by the patient registration form? Do you need it in your pull request?

suthagar23 · 2018-06-16T04:55:12Z

Ohh @dkayiwa , 😄 I thought to use this PR for only create that accessLocation fragment.

So then, I have updated this PR with filters for PatientSearch. Please have a look again here.

dkayiwa · 2018-06-16T18:12:49Z

This pull request still has too much more than the first use case that we are dealing with.

dkayiwa · 2018-06-24T08:28:11Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+                return false;
+            }
+            else {
+                if(!personAttribute.getValue().equals(location.getUuid())) {


Is it efficient to call location.getUuid() for each and every patient?

We can improve it by replacing UUID.

dkayiwa · 2018-06-24T08:31:25Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+            return patientList;
+        }
+
+        public Boolean isPatientConstainsLocation(Location location, PersonAttribute personAttribute ) {


This method name is still confusing based on its parameters. The grammar of the name is also not correct.
Just get rid of it.

Oh, Sorry small mistake on Contains. Let me know if there are any issues with this fixed method name.

dkayiwa · 2018-06-24T12:52:52Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+            return patientList;
+        }
+
+        public Boolean isPatientContainsLocation(String locationUuid, PersonAttribute personAttribute ) {


Looking at the method name, is there anything in this method that has to do with patient?

That's why I thought to replace by isPatientAttributeContainsLocation(). Wha do you think about this name?

Can you just do a 10 minutes google search about good method names?

dkayiwa · 2018-06-25T12:52:35Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+            return patientList;
+        }
+
+        public Boolean compare(String value1, String value2) {


Do we have to make this public?
Can we also reduce the number of return statements in this method?

We can make it as private.
I have fixed it as well and reduced the number of returns.

dkayiwa · 2018-06-25T12:59:28Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+
+        private Boolean compare(String value1, String value2) {
+            if (StringUtils.isNotBlank((value1)) && StringUtils.isNotBlank((value2))) {
+                if(value1.equals(value2)) {


Can you also reduce the number of if statements?

Reduced by removing on IF condition

dkayiwa · 2018-06-25T13:38:01Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+        }
+
+        private Boolean compare(String value1, String value2) {
+            if (StringUtils.isNotBlank((value1)) && StringUtils.isNotBlank((value2))) {


Can you reduce to one return statement?

dkayiwa · 2018-06-25T14:10:10Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+import org.apache.commons.lang3.StringUtils;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.openmrs.*;


https://wiki.openmrs.org/display/docs/Java+Conventions#JavaConventions-Donotusewildcardimports

oh, Sorry for the mistake. I have fixed. Please check again

Did you see my latest comments on JIRA?

dkayiwa · 2018-06-26T10:41:00Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+
+                    for (Iterator<Patient> iterator = patientList.iterator(); iterator.hasNext(); ) {
+                        Patient patient = iterator.next();
+                        if (!compare(patient.getAttribute(personAttributeType).getValue(), sessionLocationUuid)) {


Did you actually test these changes by compiling the module and try to search for patients?

Yes @dkayiwa, I have tested with my local deployment. it's working for me (I already created that person attribute type and global property)

Have you tried searching when you have patients who did not save any value in the location person attribute?

Yah, there was an issue on fetching personAttribute for them. I have fixed it and updated the PR.

dkayiwa · 2018-06-27T07:10:13Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+                        Patient patient = iterator.next();
+                        PersonAttribute personAttribute = patient.getAttribute(personAttributeType);
+                        if( personAttribute != null) {
+                            if (!compare(personAttribute.getValue(), sessionLocationUuid)) {


Combine these two if statements such that you do not duplicate iterator.remove

dkayiwa · 2018-06-29T11:03:08Z

api/src/main/java/org/openmrs/module/locationbasedaccess/PatientSearchAdviser.java

+
+                    for (Iterator<Patient> iterator = patientList.iterator(); iterator.hasNext(); ) {
+                        Patient patient = iterator.next();
+                        PersonAttribute personAttribute = patient.getAttribute(personAttributeType);


While testing, i have noticed something. If some one installs the module, but with some patients who do not yet have locations, they will not be listed on search. So how are they supposed to be listed, in order to be able to edit their locations? Any ideas?

Updated.
So now, System Administrators can get the patients lists for the logged-in location + patients lists who haven't location attribute. So System Administrators can edit the patient location.
The code base is updated along with this check.

…ns on registration Removed personAttribute creation Added fixes for PR comments PR Review fixes Added minor fix Added some fixes according to the PR reviews Minor fix Changed the locationCheck method structure minor fix Changed method name Added fixes for PR reviews Added fixes for PR reviews Changed method to compare Changed Compare method Minor improvements Minor modifications Minor fix Minor fix in the methods Merged IF conditions Removed unwanted dependencies Added appUi to required module Added user role check for viewing patients

dkayiwa · 2018-07-02T17:58:54Z

Can you also add some unit tests for this functionality?

suthagar23 · 2018-07-04T16:22:29Z

I will follow the unit test methods for AOP Advices and update the unit testing for my work later.

suthagar23 force-pushed the suthagar23:LBAC-3 branch 2 times, most recently from f7baf60 to 3a86fc1 May 26, 2018

suthagar23 mentioned this pull request May 26, 2018

Implemented initial design for the location based access control #2

Closed

1 of 1 task complete

suthagar23 force-pushed the suthagar23:LBAC-3 branch from 3a86fc1 to 41eb5cf May 26, 2018

dkayiwa reviewed May 27, 2018

View changes

suthagar23 reviewed May 28, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from 41eb5cf to 03ec06d Jun 10, 2018

suthagar23 force-pushed the suthagar23:LBAC-3 branch 2 times, most recently from 0bb457c to d8fccd4 Jun 10, 2018

suthagar23 force-pushed the suthagar23:LBAC-3 branch 2 times, most recently from 5e8a9e2 to eeeef83 Jun 10, 2018

suthagar23 force-pushed the suthagar23:LBAC-3 branch from eeeef83 to e0deb09 Jun 16, 2018

suthagar23 force-pushed the suthagar23:LBAC-3 branch 3 times, most recently from 1ed360a to 0122c94 Jun 22, 2018

dkayiwa reviewed Jun 24, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch 2 times, most recently from cf38324 to f3dc711 Jun 24, 2018

dkayiwa reviewed Jun 24, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from f3dc711 to ff5d5ed Jun 25, 2018

dkayiwa reviewed Jun 25, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from ff5d5ed to 931e8ed Jun 25, 2018

dkayiwa reviewed Jun 25, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from 931e8ed to 7f0ef73 Jun 25, 2018

dkayiwa reviewed Jun 25, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from 7f0ef73 to fec3b88 Jun 25, 2018

dkayiwa reviewed Jun 25, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from fec3b88 to 4a57e1c Jun 25, 2018

dkayiwa reviewed Jun 26, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from 4a57e1c to f9acfe0 Jun 27, 2018

dkayiwa reviewed Jun 27, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch 3 times, most recently from 6f00b92 to ab9d05a Jun 27, 2018

dkayiwa reviewed Jun 29, 2018

View changes

suthagar23 force-pushed the suthagar23:LBAC-3 branch from ab9d05a to 9d18a97 Jul 2, 2018

dkayiwa merged commit 1da91c5 into openmrs:master Jul 3, 2018
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details


		public static final String PATIENT_OBJ_NAME = "PATIENT";

		public static final String SAVE_PATIENT_METHOD_NAME = "savePatient";


		public static final String ACCESS_LOCATION_PERSON_ATTRIBUTE_TYPE_NAME = "accessLocation";

		public static final String PATIENT_OBJ_NAME = "PATIENT";

openmrs / openmrs-module-locationbasedaccess

LBAC-3 Added implementation for assigning the patients to the locations on registration #4

LBAC-3 Added implementation for assigning the patients to the locations on registration #4

Conversation

suthagar23 commented May 23, 2018 • edited

Description

Ticket

Others

suthagar23 commented May 26, 2018

dkayiwa commented May 26, 2018

suthagar23 commented May 27, 2018

dkayiwa commented May 27, 2018

suthagar23 commented May 27, 2018 • edited

dkayiwa commented May 27, 2018

This comment has been minimized.

dkayiwa May 27, 2018 Member

This comment has been minimized.

suthagar23 May 28, 2018 Author Member

This comment has been minimized.

dkayiwa May 29, 2018 Member

This comment has been minimized.

suthagar23 Jun 18, 2018 Author Member

This comment has been minimized.

dkayiwa May 27, 2018 Member

This comment has been minimized.

suthagar23 May 28, 2018 Author Member

This comment has been minimized.

suthagar23 May 28, 2018 Author Member

This comment has been minimized.

dkayiwa May 29, 2018 Member

This comment has been minimized.

suthagar23 May 28, 2018 Author Member

This comment has been minimized.

dkayiwa May 29, 2018 Member

suthagar23 commented Jun 10, 2018 • edited

dkayiwa commented Jun 10, 2018

suthagar23 commented Jun 12, 2018

dkayiwa commented Jun 12, 2018

suthagar23 commented Jun 12, 2018

dkayiwa commented Jun 12, 2018

suthagar23 commented Jun 15, 2018

dkayiwa commented Jun 15, 2018

suthagar23 commented Jun 16, 2018 • edited

dkayiwa commented Jun 16, 2018

This comment has been minimized.

dkayiwa Jun 24, 2018 Member

This comment has been minimized.

suthagar23 Jun 24, 2018 Author Member

This comment has been minimized.

suthagar23 Jun 24, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 24, 2018 Member

This comment has been minimized.

suthagar23 Jun 24, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 24, 2018 Member

This comment has been minimized.

suthagar23 Jun 24, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 24, 2018 Member

This comment has been minimized.

dkayiwa Jun 25, 2018 Member

This comment has been minimized.

suthagar23 Jun 25, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 25, 2018 Member

This comment has been minimized.

suthagar23 Jun 25, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 25, 2018 Member

This comment has been minimized.

suthagar23 Jun 25, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 25, 2018 Member

This comment has been minimized.

suthagar23 Jun 25, 2018 Author Member

This comment has been minimized.

dkayiwa Jun 25, 2018 Member

This comment has been minimized.

dkayiwa Jun 26, 2018 Member

suthagar23 commented May 23, 2018 •

edited

suthagar23 commented May 27, 2018 •

edited

dkayiwa May 27, 2018
Member

suthagar23 May 28, 2018
Author Member

dkayiwa May 29, 2018
Member

suthagar23 Jun 18, 2018
Author Member

dkayiwa May 27, 2018
Member

suthagar23 May 28, 2018
Author Member

suthagar23 May 28, 2018
Author Member

dkayiwa May 29, 2018
Member

suthagar23 May 28, 2018
Author Member

dkayiwa May 29, 2018
Member

suthagar23 commented Jun 10, 2018 •

edited

suthagar23 commented Jun 16, 2018 •

edited

dkayiwa Jun 24, 2018
Member

suthagar23 Jun 24, 2018
Author Member

suthagar23 Jun 24, 2018
Author Member

dkayiwa Jun 24, 2018
Member

suthagar23 Jun 24, 2018
Author Member

dkayiwa Jun 24, 2018
Member

suthagar23 Jun 24, 2018
Author Member

dkayiwa Jun 24, 2018
Member

dkayiwa Jun 25, 2018
Member

suthagar23 Jun 25, 2018
Author Member

dkayiwa Jun 25, 2018
Member

suthagar23 Jun 25, 2018
Author Member

dkayiwa Jun 25, 2018
Member

suthagar23 Jun 25, 2018
Author Member

dkayiwa Jun 25, 2018
Member

suthagar23 Jun 25, 2018
Author Member

dkayiwa Jun 25, 2018
Member

dkayiwa Jun 26, 2018
Member

suthagar23 Jun 26, 2018
Author Member

dkayiwa Jun 26, 2018
Member

suthagar23 Jun 27, 2018
Author Member

dkayiwa Jun 27, 2018
Member

suthagar23 Jun 27, 2018
Author Member

dkayiwa Jun 29, 2018
Member

suthagar23 Jul 2, 2018
Author Member