Configuring apps in Bahmni dashboard

This is regarding BAH-441. In Bahmni, home page we can configure various apps like Clinical, Registration, Reports. In one of the Bahmni implementations, they requirement is to have an app similar to clinical (in addition to the default clinical app) but only prescribe drugs. We were following the approach mentioned here. However with the set of roles and privileges in product, since we are using the same code as in clinical it now requires most of the privileges in clinical. But the person just enters the drugs prescribed by the doctor and is not supposed to see other information like observations/Diagnosis… Is there a better way to achieve this?

@arjun please feel free to add if I have missed anything. @angshuonline, @darius, @mksd, others please suggest.

If we allow these apps (clinical, registration, etc) to be duplicated so that different variants of them are available on the homepage with different configurations, then we cannot be hardcoding privilege checks from within the app code, but rather we must externalize these into the configuration.

Does the code in question where the app:clinical check is newly hardcoded have access to the extension config (e.g. bahmniBilling from https://bahmni.atlassian.net/wiki/x/HJ7mBg)? I’m assuming it doesn’t because that’s an extension, not the app itself.

The way this general idea is handled in the OpenMRS reference application is by having something called an “App Template”, which you can then instantiate multiple times, and each instance might require different privileges, or have different configuration. (Here’s an example where the Capture Vitals app is actually an instance of the Find Patient app template.) In practice people have found this confusing, and I wouldn’t necessarily recommend that we follow the template exactly.

One thing to note in the refapp example is that https://github.com/openmrs/openmrs-module-referenceapplication/blob/referenceapplication-2.7.0/omod/src/main/resources/apps/vitals_app.json#L11 specifies which variant of the app (with appId) in the url, and maybe we can do something like that approach?

Stepping back, the right thing to do is to introduce a properly-reusable workflow for doing "app on homepage, accessible to certain users, that does: standard find patient => standard choose a patient => custom action.

The way medication is entrenched onto clinical, I am not sure how we can rectify this easily apart from serious some refactoring (e.g. consider medication itself as a pluggable sub-app).

I don’t remember everything, but few thoughts to think about the problem.

  1. Clinical is not an app, it is a shortcut (perhaps a product level app but not technically). Dashboard, Prescription, Observation, etc are apps. Consultation is also an app in a way that displays multiple apps inside it.
  2. So, following from that. Clinical can be used as a namepsace but assigning and deriving permissions based on that would kill the configurability.

Each app should have their own permissions independent of other apps. Again, the apps shouldn’t derive their permissions from “Clincial”. To make this process easier, I remember we defined product in-built roles which provided all permissions necessary - so that the implementer works only at the role level and never has to to think about permissions.

Have we come up with a sufficient solution this?

Per Vivek’s point, is it feasible to remove the overall permission check from “Clinical”, and replace it with individual lower-level checks?

As a quick impl-specific fix we had decided to create a new privilege at the implementation and use it to provide access to clinical queues (Basically not use the hardcoded privileges) The fix was also acceptable, as i realised unfortunately the billing user inadvertently had access to dashboard and related privileges (which is quite a big spectrum as it seems the the other tabs are “angular children” of dashboard or something like that). This was existing from a past few release at least. So restriction of access was broken anyways. So only thing we could fix for now is what majorly got broken in this release, that is due to the forced app:clincal privilege the billing person seeing clinical queues also. The creation of new custom privilege → using them for clinical app queues → assigning them to all the users who are supposed to have access and not assigning them to billing person will not show up the clinical queues to billing person.

The bigger design discussion should continue, i think. Could be one of the items for our PAT.

Giving a user access to a section within Clinical, eg Clinical-App-Treatment, seems to give them access to every other section of Clinical-App e.g. Diagnoses, despite the :

"requiredPrivilege": "app:clinical:diagnosisTab"

Is there a way around this?

UPDATE: I just discovered the role Program-App was giving access to all the sections, so can IGNORE this reply.