However setting it up as per the steps mentioned on the wiki doesn’t work. With a quick review of the code, i see some code in Bahmni apps reports to receive appName but the code to pass the appName seems to be missing.
Has anyone seen this working ever? Am i missing something?
Well, with disclaimer that my knowledge of the codebase is basic, i didn’t find where the appName is getting passed.
when i setup a new app/extension with the appName parameter in configuration, it still didn’t get passed on to this line when checking in debug (and of course it wasn’t showing the intended new report app)
Rather, if i may suggest, this is a 5 min thing to try out , so if you could try it out and see if it works for you that would be faster for us to understand where the problem is.
The problem is not just openmrs-module-bahmniapps. bahmni-reports does not support handling multiple file config urls. There is only one reports.config.url that can be configured in bahmni-reports. This looks like a feature that was planned but partially reverted. Might as well delete that wiki page (I can’t find my login button, so will need help here).
The original problem we set out to solve was that we had a long list of reports and needed a way to segregate them. There are 2 ways I can think of to fix this problem
I think its the same endTB requirement for which this feature was started to build.
may be @sdeepak or @prabhuawasthi will be able to throw light on why a multiple apps approach was taken to solve this problem.
my guess was that it could have been lower effort to do it that way. and also leverage the privilege feature which already exists for apps. say, one app is EMR reports focussed and other pharmacy/ERP focussed. It would be of interest to restrict usage of particular group of reports to specific users.
Of course, the privilege feature could be added to tabs as well.
@arjun can you do a quick lo-fi mockup of how you think this should work, as well as a quick sketch of how you think the config would look?
Personally I prefer having groups/tabs/sets, versus multiple apps, but it’s up to you which you think works better based on your understanding of the use case. In the long run we could actually support both of these…
(Broadly speaking, we have a shortage of JIRA tickets that are small/medium in size, and clearly ready for work. To the extent that you can help us get tickets into this state, then the dev team can pick from among these.)