All dashboard tabs *do* have application-level privileges already. At least in 1.9.x, patientDashboardForm.jsp has:
<openmrs:hasPrivilege privilege="Patient Dashboard - View Overview Section"> <openmrs:hasPrivilege privilege="Patient Dashboard - View Regimen Section"> <openmrs:hasPrivilege privilege="Patient Dashboard - View Visits Section"> <openmrs:hasPrivilege privilege="Patient Dashboard - View Encounters Section"> <openmrs:hasPrivilege privilege="Patient Dashboard - View Demographics Section"> <openmrs:hasPrivilege privilege="Patient Dashboard - View Graphs Section"> <openmrs:hasPrivilege privilege="Form Entry"> However looking at patientOverview.jsp I see we refer to the underlying API-level privileges: <openmrs:hasPrivilege privilege="View Patient Programs"> <openmrs:hasPrivilege privilege="View Relationships"> <openmrs:hasPrivilege privilege="View Allergies"> <openmrs:hasPrivilege privilege="View Problems"> Seems like we should write a ticket to: 1. introduce new privileges like "Patient Overview - View Programs Section", etc 2. use those in all dashboard portlets rather than the API counterparts 3. do a liquibase changeset so that every role that has "View Patient Programs" also gets "Patient Overview - View Programs Section", etc. (That way nobody loses the ability to see something they currently see.) Dave, would that help? Daniel, want to do this? -Darius On Wed, May 9, 2012 at 2:33 PM, Dave Thomas <[email protected]> wrote: > Burke, sorry for not being clear before. I think what you said in #1 is > pretty much what i'm asking for. > > The terminology can be worked out (to use your example 'Access' could > imply API-level privileges, and 'View' could imply app-level privileges), > but the important thing to me would be to not have 'Access Patient Data' > sometimes be applied at the API level and sometimes applied at the app > level. With 'Access Patient Data' used at both the API and app layers, if > I restrict 'Access Patient Data' for a user, it is incredibly difficult to > tell what i've actually restricted. This is when pieces of the > application, other than the one I was trying to restrict, start throwing > errors unexpectedly (per mark's example). > > Part two of this argument (and maybe this is a different discussion) would > be that once there was a clear distinction between api and app level > privileges, the app level privileges could start to reflect actual UI > components a little more. If each portlet on the patient dashboard had its > own privilege for example, like 'view regimen tab', the UI would be a LOT > more easy to customise in a meaningful way using privileges and roles. > > d > > > On Wed, May 9, 2012 at 1:43 PM, Burke Mamlin <[email protected]>wrote: > >> 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]> 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 <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]> 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> **** >>> >>> ** ** >>> ------------------------------ >>> >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> **** >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>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]
