Thanks to @mksd for walking me and others through a plan for O3 access privileges recently. Here’s my understanding - I want to confirm it here before I document this on the wiki.
1) For actual backend privilege set-up (Role Based, Location Based, etc etc): We recommend using the Data Filter Module.
This is used in production and strongly validated. But, it’s not currently a default part of the 3.x RefApp; you can choose to add it. The Data Filter Module is highly generic, allowing any filtering strategy you can think of - users can define filtering strategies to make data available to some users.
E.g. One large org is already using it for 2 use cases: Functional Level: Location-Based Access & Program-Based Access. E.g. “I’m a Physiotherapist at Site X → I can see Rehab data for Site X.”
2) For further frontend widget configuration (eg. this privilege should have access to this widget), @florianrappl reported in the October 2021 3.x Squad call that a new Privilege layer for extensions had been added and works online and offline. You can see a screenshot below.
This is an especially pressing question for orgs that are using 3.x at sites that have many different kinds of programs - eg HIV as well as NCD, ANC, etc etc - and have concerns about users inappropriately seeing sensitive pt chart widgets.
CC @slubwama
I’m not sure what the differences are between the Data Filter Module and the Privileges Helper Module - @dkayiwa can you see an obvious benefit to one over the other?
One caveat to the Data Filter Module: Apparently this cannot be used in Bahmni, because the module requires that all the OMRS modules use the ORM hibernate layer, which is bypassed in many occurrences in Bahmni. (This is just what I have heard; I’m open to correction.)
The Privilege Helper Module simply helps you figure out which privileges you need to perform a particular task. It does not enforce the privileges as done by the Data Filter Module. Privilege Helper Module - Documentation - OpenMRS Wiki
Also I would not want to mislead the reader about authorization within OpenMRS.
OpenMRS - the backend - provides an authorization mechanism out of the box, as it should be expected from a Spring app. There is no need to add extra add-ons like Data Filter for this.
If you need a much more fine grained control of who can access what data and under which circumstances, and if those circumstances tend to become implementation-specific, then we would recommend using the Data Filter module.
Am not sure wether this is the right place to ask this.
How do i for example give access of some frontend apps to a provider based on their roles and priviledges registered in the backend or configured via Legacy Admin UI.
For example a provider with a lab role cannot access appointments and service queues apps ?
Not role, but privilege. Yes, that ticket was done. I don’t know if there’s good documentation to point to, but look for “Display conditions” in the Implementer Tools config view.
Alright thanks @bistenes will look into it. In an ideal setting we really need to make sure different providers have different levels of access based on their Roles & privileges, otherwise the fall back plan would be DistoHIS which gives more freedom for lab, pharmacy, billing, dispensing e.t.c
