+1 for this. We also could provide a little bit of granularity by also creating a role where every read-only API privilege check passes.
________________________________________ From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Michael Seaton [msea...@pih.org] Sent: Friday, May 18, 2012 11:27 AM To: openmrs-deve...@listserv.iupui.edu Subject: Re: [OPENMRS-DEV] Roles and Privileges In this vein, here is a use-case I would like to suggest, based on many of the great suggestions I've heard: * Create 2 types of privileges - API-level and Application-level * Provide a "System Developer"-like role in which every API-level privilege check always passes, but which Application-level privileges need to be set * Re-factor our Web Application to refer only to Application-level privileges This would allow for implementations, if they chose, to effectively turn off API-level privileges, but to still restrict the types of activities that users could perform within the EMR application. We can debate around the merits of turning off API-level privileges, and whether or not they are necessary, but this step would go a long way to have OpenMRS "get out of the way" until better management of API-level privileges is supported. I think the above could be done within a Sprint pretty easily, and modules that currently do API-privilege checking would not be impacted, but could migrate over to the Application-privilege checking when appropriate ________________________________________ From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Mark Goodrich [mgoodr...@pih.org] Sent: Friday, May 18, 2012 10:49 AM To: openmrs-deve...@listserv.iupui.edu Subject: [OPENMRS-DEV] Roles and Privileges 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<mailto: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] _________________________________________ 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]
