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 _________________________________________ 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]
