New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Jul 3, 2018

Conversation

Projects
None yet
2 participants
@suthagar23
Member

suthagar23 commented May 23, 2018

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

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 May 26, 2018

Member

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

Member

suthagar23 commented May 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa May 26, 2018

Member

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

Member

dkayiwa commented May 26, 2018

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

@suthagar23

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 May 27, 2018

Member

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.

Member

suthagar23 commented May 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa May 27, 2018

Member

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

Member

dkayiwa commented May 27, 2018

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

@suthagar23

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 May 27, 2018

Member

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

Member

suthagar23 commented May 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa May 27, 2018

Member

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

Member

dkayiwa commented May 27, 2018

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

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

This comment has been minimized.

@dkayiwa

dkayiwa May 27, 2018

Member

Shouldn't this be on PersonService?

@dkayiwa

dkayiwa May 27, 2018

Member

Shouldn't this be on PersonService?

This comment has been minimized.

@suthagar23

suthagar23 May 28, 2018

Member

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.

@suthagar23

suthagar23 May 28, 2018

Member

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.

This comment has been minimized.

@dkayiwa

dkayiwa May 29, 2018

Member

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

@dkayiwa

dkayiwa May 29, 2018

Member

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

This comment has been minimized.

@suthagar23

suthagar23 Jun 18, 2018

Member

Nope, AFAIK We need to access this PatientService

@suthagar23

suthagar23 Jun 18, 2018

Member

Nope, AFAIK We need to access this PatientService

@suthagar23

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 10, 2018

Member

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

image

Member

suthagar23 commented Jun 10, 2018

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

image

@dkayiwa

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jun 10, 2018

Member

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

Member

dkayiwa commented Jun 10, 2018

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

@suthagar23

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 12, 2018

Member

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

Member

suthagar23 commented Jun 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jun 12, 2018

Member

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?

Member

dkayiwa commented Jun 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 12, 2018

Member

Yes @dkayiwa. I totally understood.

It will be a solution for the Case-1.

Then shall I create another ticket for case-2?

Member

suthagar23 commented Jun 12, 2018

Yes @dkayiwa. I totally understood.

It will be a solution for the Case-1.

Then shall I create another ticket for case-2?

@dkayiwa

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jun 12, 2018

Member

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.

Member

dkayiwa commented Jun 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 15, 2018

Member

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?

Member

suthagar23 commented Jun 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jun 15, 2018

Member

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?

Member

dkayiwa commented Jun 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 16, 2018

Member

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.

Member

suthagar23 commented Jun 16, 2018

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 comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jun 16, 2018

Member

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

Member

dkayiwa commented Jun 16, 2018

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

@suthagar23

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jun 17, 2018

Member

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.

Member

suthagar23 commented Jun 17, 2018

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.

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

This comment has been minimized.

@dkayiwa

dkayiwa Jun 29, 2018

Member

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?

@dkayiwa

dkayiwa Jun 29, 2018

Member

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?

This comment has been minimized.

@suthagar23

suthagar23 Jul 2, 2018

Member

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.

@suthagar23

suthagar23 Jul 2, 2018

Member

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.

Suthagar23
LABC-3 Added implementation for assigning the patients to the locatio…
…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

This comment has been minimized.

Show comment
Hide comment
@dkayiwa

dkayiwa Jul 2, 2018

Member

Can you also add some unit tests for this functionality?

Member

dkayiwa commented Jul 2, 2018

Can you also add some unit tests for this functionality?

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

1 check passed

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

This comment has been minimized.

Show comment
Hide comment
@suthagar23

suthagar23 Jul 4, 2018

Member

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

Member

suthagar23 commented Jul 4, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment