Supporting OpenMRS Reporting Module reports in the Bahmni Reports App (Quick fix, BAH-314)

Thanks @binduak!

I am personally in favour of this screen looking as much as possible like the existing one (Bahmni Reports). The reason being that I always envisioned that eventually a single reports screen would handle both types of reports (OpenMRS and non-OpenMRS).

I think it is confusing and doesn’t make sense to the end user to distinguish between ‘Reports’ and ‘OpenMRS Reports’.

Quick remark: the second column is labelled ‘First Name’ whereas it should be ‘Start Date’.

1 Like

@binduak, I agree with Dimitri that the ultimate goal should be for us to have just a single Reports app on the Bahmni home screen that lets you run either kind of report, without the end user having to know that there’s a difference.

Given that this is an interim step, I would make some minor tweaks to styling so that this looks as close to the Bahmni reports page as is feasible (e.g. left align the name column, and prefer to get rid of the footer of that datatable).

I recall that when I saw you presenting this live the way it worked is that you’d click “Run Now”, which would then enable the “Download” button. Instead I would expect this to work like the Bahmni reports app does, where clicking Run Now both triggers the run, and downloads it when ready. The OpenMRS Reporting module also supports queueing reports, so I would consider implementing a Queue button in the OWA as well (to match the Bahmni reporting app).

I think we can aggregate both Bahmni Reports and OpenMRS reports in one app but not on the same page. Bahmni Reports take startDate and endDate parameters to run the report. But OpenMRS has option to take lot of parameters types along with Date like concept, Location, Person, Boolean, User, Program…etc, though we are restricting the first version of our application to starDate and endDate.

yes…I was enabling the Download button once the reportRequest call was successful. The drawback with this approach is, user doesn’t know when the report is ready to download. He has to keep on clicking the Download button. It will be a problem when it comes to report which takes more than 1-2 minutes to process.

For this, one option is to enable the Download button only when the report is available for download. Then the user can click and download the report. This will give an option to download the same report multiple times. Or we can remove the download button as you mentioned.

yes…I have made code changes and updated the existing PR to support for queueing reports. As far as I know, the scope for the reporting UI app is to run the reports which takes startDate and endDate as parameters. This doesn’t include the queueing of the reports. @mksd can you please confirm.

True, but possibly also true for Bahmni reports as @arjun pointed out in the last PAT call. My take would be that we should assume that the ‘OpenMRS reports’ will also be parameterised with only start date and end date for now, and therefore aim at a seamless integration for both sources of reports on the same screen.

Perhaps the future will bring a Reporting Admin OWA that will revamp the current legacy UI screens, and then that could be the place to run all OpenMRS reports that can’t be run with our new screen(s).

Thoughts, @darius, @angshuonline, @arjun?

P.S. Developing shared UI components to achieve the above could be a task for RGSoC interns. Cc @danfuterman

1 Like

i think we could take this approach :

in the first version, restrict the openmrs reports to date range. In the second version, we could improve Bahmni reports to take configured parameters.

2 Likes

Yes +1 to these last two comments. For the current round of work with the assumption that OpenMRS reports, like Bahmni reports, will take only start date and end date.

Given that assumption, what would it take to make your current OWA display both the Bahmni and OpenMRS reports?

It would be excellent if the dropdown defaults were:

Start Date = 1 week ago

End Date = Today

Format = HTML

This would save a lot of time in testing of new reports.