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.
@zacbutko @mksrom @bistenes @dkigen Does this match the plan you have in mind for O3 access control?
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.
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.
On the frontend side, extension privileges can be set in code (as you show), but we also intend to make them configurable; see O3-1207.