Thanks for sharing this Mark. It sounds like our solutions for the sprint will help and are pretty much right on target.
We've discussed coming up with some pre-defined roles that the OpenMRS web application would include out of the box. As you've alluded, these could be roles that cover a collection of related API privileges like "Access Patient Demographic Data", "Access Patient Medical Data", "Update Patient Demographic Data", etc. Instead of giving all users access to *all* API privileges, which would be equivalent to simply turning off any API-level privilege checks, we need to work to making easier to handing out the right collection of API privileges. Being able to get data would be handed out pretty broadly; however, API-level permissions to update, create, void, etc. would ideally not be handed out indiscriminately. Cheers, -Burke On Fri, May 18, 2012 at 10:49 AM, Mark Goodrich <mgoodr...@pih.org> wrote: > Yesterday I ran into a real-life roles and privileges problem very > similar to the example problem I gave a week or two ago. Sine this the > roles and privileges sprint is upcoming, I figured I'd mention it here... I > think we've already got these issues covered, but wanted to reiterate since > it is a good "real-life" example. > > In the Provider Management module, the Provider Dashboard lists all of the > patients associated with a Provider. However, in the functional specs for > Provider Management, there is a requirement to have a role for users who > are able to manage providers but aren't able to view patient data. For > this role, the patients associated with a provider should not be displayed, > but, instead, the dashboard should show the number of patients that a > provider has. But, in order for the Provider Management API to calculate > this information, this role would need to have the "View Patients" > privilege, or, at least, "View Relationships" privilege. > > As was suggested earlier, one solution would be to give the user the > appropriate proxy privilege to do this calculation, but that seems like a > bad solution. > > I'd actually be fine with giving this role access to the getPatients > and getRelationships API method, as long as there was a way to do that > without giving them access to patient information via the web layer. > It seems critical to me that API-level and UI-level privileges be separated > out. We have LOTS of privileges in attempt to allow > for fine-grained access control, but those privileges are not always > "grained" in a useful way. > > Actually, from a web application level, I don't think that API-level > privileges are particularly useful, except last-resort defense in the case > that UI privileges aren't properly set up. (However, I realize that they > would be critical when using a web services access model.) In fact, if I > thought that the OpenMRS web-level privileges were well enough defined, I'd > almost consider having an option/role that allows me to give a user all > API-level privileges when they access OpenMRS through the web app. > > I just set up privileges for the Provider Management module yesterday, and > what I did was define a set of UI-level privileges that I use to > hide/display certain sections of the provider dashboard. Then I created > two separate, coarse-grained API privilegs: "Provider Management API" and > "Provider Management API - Read-only" which I think should be sufficient > for my use case. > > It might be valuable to have a way to group privileges... say like a > "Patient Service API privilege group"? Of course you could do this via a > role, but a "Patient Service API" role doesn't seem to be the way role was > intended to be used. > > And finally, a big +1 for creating a module that records privilege checks > to faciliate administration. Yesterday I had to use a trial-and-error > approach to figure out exactly what privileges were required to access > certain parts of the Provider Management site so that i could define roles > appropriately. > > Take care, > Mark > > > > > ------------------------------ > 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]
