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 <bu...@openmrs.org> 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 <bu...@openmrs.org> 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 <b...@openmrs.org> 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<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
