A step below data level privileges is encounter based privileges, which sometimes can be used as a "reasonably" effective workaround to some of the data access privileges wishes. If there is any discussion to be had, would be good to consider this.
On 9 May 2012 20:55, Mark Goodrich <[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]] On Behalf Of Dave Thomas > Sent: Wednesday, May 09, 2012 2:51 PM > To: [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]> wrote: > > (bringing this conversation about preparing for the Roles & Privileges > sprint onto the dev list) > > > > Reviewing the notes 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]> 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]> 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 from OpenMRS Developers' mailing list > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > ________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
