Yeah, #1 is the solution that seems to make the most sense. There are lots of examples of this, especially as you start adding your own custom modules.
Mark From: [email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin Sent: Wednesday, May 09, 2012 4:44 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Roles and Privileges Sprint Mark, This is an interesting point. Your example helps me understand Dave's point and suggests that we should distinguish between "Access Patient Data" and "View Patient Data" – i.e., the use of "View" in the privilege term describing API-level access to data per our conventions implies that getting data at the API level also means that the user should be able to view it within the application, which is not always the case. In your example (a person being able to view aggregate patient data without viewing individual patient records), we have two choices: 1. Grant the user "Access Patient Data" as the API-level privilege, meaning that they would be permitted to execute API calls that return patient information, but would not imply that the application should let them view the data directly. 2. Allow the methods that need to access patient data to proxy privileges for the user. The first seems like the better option to me. Proxying privileges seems like a hacky way to override privileges that are there for a reason. The first option will take some effort (maybe more than the upcoming sprint can muster), but seems like a better long-term solution. Maybe we can come up with a way to start heading that direction. -Burke On Wed, May 9, 2012 at 3:55 PM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: +1 for this. We’ve run into issues with this a lot. For instance, say you have a user who should not be able to view patients, but should have access to a report of aggregate patient data that calls getPatients() behind the scenes to perform the necessary calculations. If you take away the “view patient” privilege from the user, they’ll get a stack trace when they attempt to execute the report. This issue has been prevalent enough for us that we basically are unable to use privileges and roles for access control … Mark From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Dave Thomas Sent: Wednesday, May 09, 2012 2:51 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Roles and Privileges Sprint If i can weigh in on a discussion of roles and privileges briefly, I've found (and maybe things are improved in versions greater than 1.6.x) that we've run into trouble when a privilege is used both at the api and web layer. This happens when we want to hide something in the UI that is wrapped in a <privilege/> tag, but then when we remove that privilege for a user, it turns out that the same privilege was wrapped around a couple of API methods, causing unexpected and hard-to-track-down UI problems across all of openmrs. If there's a dedicated pass at roles+privileges, has there been any thought to separating api privileges from ui privileges? I kind of feel like this is low-hanging fruit. This wouldn't even need re-architecting, maybe just privilege naming conventions? Or is the general sense that this type of problem has disappeared in newer versions? d On Wed, May 9, 2012 at 10:29 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: (bringing this conversation about preparing for the Roles & Privileges sprint onto the dev list) Reviewing the notes<http://notes.openmrs.org/2012-roadmap> on Roles & Permissions section from Jembi & PIH, it looks like there are some fundamental improvements requested: * Ship OpenMRS with pre-defined roles * Better documentation on managing roles (avoiding pitfalls) * More informative handling of privilege exceptions (make it easier to understand where/which privileges are missing) * Data-level permissions (restricting access to specific data based on privileges) We've had prior conversations about improving roles/privileges: * Avoiding the common pitfall of conflating organizational roles (job title) with application roles (authorization within OpenMRS); they may align early on in simple systems, but exceptions are common over time or as a a system grows. * Creating privilege groups vs. programmatically defined roles – e.g., a web page wants to limit access to those who have a set of privileges. * Introducing location-based privileges There seem to be some potential short-term wins that could be done in the sprint: * Improve our documentation to better introduce people to roles & privileges and cover the common pitfalls. * Improve privilege error messages in core and/or create a module that makes it easier to troubleshoot privilege errors (e.g., log all privilege checks during an operation and present the unique list of privileges and/or roles that would cover the operation, allowing someone to step through a workflow as superuser and then see the list of privileges required to complete the workflow). * Come up with some basic application roles that can be pre-defined within OpenMRS (ship with the application) * Design (and, if possible, implement) an approach for privilege groups or system roles (i.e., uneditable sets of privileges that applications can program against) Data-level privileges (limiting access to data based on privileges) would be a terrific addition, but I'm afraid it will take more design that we can muster between now & the beginning of this sprint. Maybe we could come up with some small but useful first attempts at solving this problem (e.g., a module requiring permissions to access certain observations … or a module that limits access to specific patients based on permissions). Cheers, -Burke On Wed, May 9, 2012 at 9:49 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: Looking back at notes from AMPATH, the only reference to anything close to roles & privileges I found was the desire for the Data Entry Statistics Module to have a basic view privilege that allows a data assistant to see only his/her own statistics. -Burke On Wed, May 9, 2012 at 9:44 AM, Ben Wolfe <[email protected]<mailto:[email protected]>> wrote: Dawn found this link for me: http://notes.openmrs.org/2012-roadmap Is has the (mostly raw) notes from the calls we had with Jembi/PIH/AMPATH. Daniel, can you tease out the topics from that and the other text below in the next 4 hours? Ben ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
