RCM-109 Added patient verification to return Cohorts objects for the serviceMethods

[suthagar23]

Descriptions

In reporting compatibility module used the org.openmrs.cohort.Cohort class instead of org.openmrs.Cohort class. So other modules which are using these service methods needed to add the reporting compatibility module as the required module.

To avoid this requirement, A patient verification is added to the Cohort Membership methods.

Ticket Information

Ticket : https://issues.openmrs.org/browse/RCM-109

[dkayiwa]

Instead of removing the patient ids from the collection, can't we just filter them at source? Where they are loaded from the database?

[dkayiwa]

Instead of removing the patient ids from the collection, can't we just filter them at source? Where they are loaded from the database?

[suthagar23]

Do you mean to put this here? https://github.com/openmrs/openmrs-module-reportingcompatibility/blob/master/api/src/main/java/org/openmrs/module/reportingcompatibility/service/db/HibernateReportingCompatibilityDAO.java#L198

[suthagar23]

Do you mean to put this here? https://github.com/openmrs/openmrs-module-reportingcompatibility/blob/master/api/src/main/java/org/openmrs/module/reportingcompatibility/service/db/HibernateReportingCompatibilityDAO.java#L198

[suthagar23]

Instead of adding this to the DAO resource (we might also need to add for multiple lines), why we do not add this to the Cohort constructor here (just some places will be affected - Constructor,setMemberIds and addMember methods) ?
https://github.com/openmrs/openmrs-module-reportingcompatibility/blob/master/api/src/main/java/org/openmrs/cohort/Cohort.java#L70

[suthagar23]

Instead of adding this to the DAO resource (we might also need to add for multiple lines), why we do not add this to the Cohort constructor here (just some places will be affected - Constructor,setMemberIds and addMember methods) ?
https://github.com/openmrs/openmrs-module-reportingcompatibility/blob/master/api/src/main/java/org/openmrs/cohort/Cohort.java#L70

[dkayiwa]

Looks fine to me for now. As long as those who do not have our module installed will not be affected.

[dkayiwa]

Looks fine to me for now. As long as those who do not have our module installed will not be affected.

[suthagar23]

@dkayiwa Do we only use the Cohort objects for Patients? If we are using the Cohorts for other members then We can't add this patient verification to the Cohort Class. Because it will caused the problems for other members.
If we are using Cohort for other members(like for persons and users) , then we should add these to the DAO resource, otherwise, we can add this to the Cohort class. What do you think?

[suthagar23]

@dkayiwa Do we only use the Cohort objects for Patients? If we are using the Cohorts for other members then We can't add this patient verification to the Cohort Class. Because it will caused the problems for other members.
If we are using Cohort for other members(like for persons and users) , then we should add these to the DAO resource, otherwise, we can add this to the Cohort class. What do you think?

[dkayiwa]

Are there any major disadvantages of adding this to the DAO layer?

[dkayiwa]

Are there any major disadvantages of adding this to the DAO layer?

[suthagar23]

We need to change multiple lines to make the changes in multiple class files. But going for the Cohort will only need to change few lines.
But the parameters and the methods are contained "patients" in their names in the Cohort Class. So I think mostly we will use the Cohorts for the patients. Is it Right?

[suthagar23]

We need to change multiple lines to make the changes in multiple class files. But going for the Cohort will only need to change few lines.
But the parameters and the methods are contained "patients" in their names in the Cohort Class. So I think mostly we will use the Cohorts for the patients. Is it Right?

[dkayiwa]

Yes that is right.

[dkayiwa]

Yes that is right.

[suthagar23]

@dkayiwa I have changed the implementation. Please review again THanks.

[suthagar23]

@dkayiwa I have changed the implementation. Please review again THanks.

[dkayiwa]

Is it worth making all these extra calls when our module is not installed?

[dkayiwa]

Is it worth making all these extra calls when our module is not installed?

[suthagar23]

Yes, I also thought this.
I have added Global Property("Cohorts.checkForNullPatients") to track this extra work. If the GP points to true, then do the extra works else just ignore them by default.
The GP value should be created/set to True while starting our module.

[suthagar23]

Yes, I also thought this.
I have added Global Property("Cohorts.checkForNullPatients") to track this extra work. If the GP points to true, then do the extra works else just ignore them by default.
The GP value should be created/set to True while starting our module.

[dkayiwa]

Why create an extra gp? Can't you use the same logic like you used for the reference application?

[dkayiwa]

Why create an extra gp? Can't you use the same logic like you used for the reference application?

[suthagar23]

In the reference application also, we have created a GP through our module and used that. What do you mean by the logic?
If you have meant about the same GP, then we might not use that here since the name of that GP doesn't relate to this requirement (See here).

[suthagar23]

In the reference application also, we have created a GP through our module and used that. What do you mean by the logic?
If you have meant about the same GP, then we might not use that here since the name of that GP doesn't relate to this requirement (See here).

[dkayiwa]

Closing this for now until when we get feedback from the 0.1.0 release

[dkayiwa]

Closing this for now until when we get feedback from the 0.1.0 release