I am working on REPORT-288 - Incorporate the Location Hierarchy capabilities into the reporting module. When running reports that have a location parameter and a location that has sublocations is selected at runtime, the report should also include these sublocations in its final calculation. I have read @mseaton comment about how to tackle this and successfully implemented it. I have gone through all Definitions that have a @List<Location> and added a excludeSublocations property as @mseaton suggested. Added a getAllSublocations method that will return all locations and their sublocations if expludeSublocations is false. And modified the evaluators of all these definitions to make use of getAllSublocations method. You can see my commit here commit. Its not in a pull request yet as I’m still writing unit tests. According to the ticket comments, this issue is resolved and whats left is just to write unit test and open a pull request.
But it does not solve the original problem I was trying to solve. The solution proposed during the last design forum only talked about cohort Definitions that have a List. That is those that filter by location. But my client uses SqlCohortQuery which in fact also filters by location but does not have a List in its declaration. So the solution proposed by the previous design forum could not handle that.
I have tested all the other cohort definitions from the interface and they follow sublocations as intended but unfortunately SqlCohortQuery is still unable to follow sublocations. For example a query like
SELECT patient_id from patient_program WHERE location_id = :location
should follow sublocations of the :locations parameter. What I want to know is how I can intercept that query before it is executed and modify it to include sublocations even if the user does not see it. I already talked to @dkayiwa about this on IRC and he recommends I request for a design forum. I see this Wednesday is free and I’m on a limited time schedule I would love to have this Wednesday to discuss this.
I know you all have very busy schedules but I will appreciate it a lot if @mseaton, @dkayiwa, @darius and @wyclif will be able to make it for this call.
cc @jthomas