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

[suthagar23]

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]

@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.

[suthagar23]

@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]

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

[dkayiwa]

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

[suthagar23]

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.

[suthagar23]

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]

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

[dkayiwa]

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

[suthagar23]

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')

[suthagar23]

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]

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

[dkayiwa]

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

[dkayiwa]

Shouldn't this be on PersonService?

[suthagar23]

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.

[dkayiwa]

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

[suthagar23]

Nope, AFAIK We need to access this PatientService

[suthagar23]

@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!

[suthagar23]

@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]

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

[dkayiwa]

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

[suthagar23]

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

[suthagar23]

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]

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

1. Person attributes are stored normally using the patient registration form which you have configured as such.
2. 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?

[dkayiwa]

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

1. Person attributes are stored normally using the patient registration form which you have configured as such.
2. 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]

Yes @dkayiwa. I totally understood.

It will be a solution for the Case-1.

Then shall I create another ticket for case-2?

[suthagar23]

Yes @dkayiwa. I totally understood.

It will be a solution for the Case-1.

Then shall I create another ticket for case-2?

[dkayiwa]

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.

[dkayiwa]

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]

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?

[suthagar23]

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]

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?

[dkayiwa]

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]

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.

[suthagar23]

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]

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

[dkayiwa]

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

[suthagar23]

I have removed that G.Property implementation from the PR. Now the PR just contains the implementations to return patients in the logged in location.

[suthagar23]

I have removed that G.Property implementation from the PR. Now the PR just contains the implementations to return patients in the logged in location.

[dkayiwa]

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?

[suthagar23]

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.

[dkayiwa]

Can you also add some unit tests for this functionality?

[dkayiwa]

Can you also add some unit tests for this functionality?

[suthagar23]

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

[suthagar23]

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