Thanks for bringing this up, @grace. OpenMRS frontend and backend would benefit greatly from a thoughtful approach to privileging. We started with privileges & roles, where privileges controlled access to specific API methods and roles allowed the privileges to be grouped for easier assignment/management. This worked well initially, but ran into a some problems that we’re likely to exacerbate or recreate on the frontend if we’re not careful:
- As the number of privileges grow, they become difficult for admins to manage. Roles can help assign groups of privileges, but admins can’t easily know which privileges are needed for a workflow. This led OpenMRS 2.x to a hacky approach of granting all backend privileges to users and managing feature-level privileges in the frontend, which isn’t a viable approach for OpenMRS 3.
- If frontend features aren’t behaving as expected for a user because of a privileging issue, how does an admin troubleshoot the problem?
- Can we come up with a way of more effectively communicating/documenting the set of privileges needed or used by a module/widget. In the past, we considered the idea of “privilege groups” as a way to define a collection of privileges needed for a feature/module, but this never got implemented.
- Roles (groups of privileges) are often misinterpreted or created as organizational roles (“Doctor” or “Nurse”) when they are really intended to be application roles (e.g., “Can write orders” or “Can view nursing dashboard”) – i.e., application roles should focus on what a user can do with the application and not their job title.
- The UserGroup feature could help us in separating organizational roles from application roles.