Roles and Privileges

classic Classic list List threaded Threaded
6 messages Options
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
 
 
 
 

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges

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 <[hidden email]> 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
 
 
 
 

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges

In reply to this post by Mark Goodrich-2
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: [hidden email] [[hidden email]] On Behalf Of Mark Goodrich [[hidden email]]
Sent: Friday, May 18, 2012 10:49 AM
To: [hidden email]
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:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges

+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: [hidden email] [[hidden email]] On Behalf Of Michael Seaton [[hidden email]]
Sent: Friday, May 18, 2012 11:27 AM
To: [hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Mark Goodrich [[hidden email]]
Sent: Friday, May 18, 2012 10:49 AM
To: [hidden email]
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:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges

I agree that we need to improve privilege-handling, but I don't agree that the best approach is to disable/bypass all API privilege checking.

Are you suggesting that re-create a duplicate application-level privilege for Managing Concepts and bypass the existing privilege for manage concepts?  Should anyone using the application be able edit users if they can find the right URL that lacks the application-level privilege checking?  I 100% agree with improving permission handling to make things more manageable, but I don't agree with wholesale bypassing of API privileges any more than I would propose solving a Tomcat permissions problem by running it as root.  API privilege checking is there for a reason.  And, while there are many cases where application-level privileges are needed/justified, there are many cases where separate application-level privileges would only be redundant.

Making the changes planned in the sprint, providing an easy mechanism for granting all of the "Get" privileges (e.g., an out-of-the-box role), creating some conventions for handling application-level permissions, and having improved tools for troubleshooting privilege problems should go a long way in improving the situation without having to completely disable any API-level security.

-Burke

On Fri, May 18, 2012 at 11:52 AM, Mark Goodrich <[hidden email]> wrote:
+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: [hidden email] [[hidden email]] On Behalf Of Michael Seaton [[hidden email]]
Sent: Friday, May 18, 2012 11:27 AM
To: [hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Mark Goodrich [[hidden email]]
Sent: Friday, May 18, 2012 10:49 AM
To: [hidden email]
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:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges

Hi Burke,

I was definitely expecting this response :)  I am not suggesting that we re-create a duplicate application-level privilege for Managing Concepts necessarily.  What I am suggesting is just an extension of what Dave and Mark have already suggested - that our application should have a different type of "privilege" that allows for showing / hiding or enabling / disabling features, which is based on the granulariy of the application and not based on the design of the API.  And it should be clear how to "customize" the features available by role using these privileges without unintended side-effects.

The reality is that there is already an out-of-the-box mechanism for bypassing privilege checking - it's called the "System Developer" role.  Many implementations use this role more than they should because they do not trust, nor do they know how best to configure, what privileges they need to use the application.  Situations that Mark describes where one part of the application bombs due to some privilege check that is totally irrelevant or designed for a different purpose is not uncommon.  So many implementations just give out the System Developer privilege to let their users get on with it and use the system, rather than continually deal with this support issue.

Ultimately, what I am proposing is a solution that would make the System Developer role more secure, by eliminating the automatic pass it gets on the Application-level, while still supporting it on the API-level.  So, although I agree that this is not necessarily our strategic long-term solution, I fail to see why it would be a bad idea, since it would make the application more secure, not less secure, than it currently is, and would provide infinitely more possibilities for implementations to customize their UI experience for users in different roles.

Cheers,
Mike


On 05/18/2012 12:17 PM, Burke Mamlin wrote:
I agree that we need to improve privilege-handling, but I don't agree that the best approach is to disable/bypass all API privilege checking.

Are you suggesting that re-create a duplicate application-level privilege for Managing Concepts and bypass the existing privilege for manage concepts?  Should anyone using the application be able edit users if they can find the right URL that lacks the application-level privilege checking?  I 100% agree with improving permission handling to make things more manageable, but I don't agree with wholesale bypassing of API privileges any more than I would propose solving a Tomcat permissions problem by running it as root.  API privilege checking is there for a reason.  And, while there are many cases where application-level privileges are needed/justified, there are many cases where separate application-level privileges would only be redundant.

Making the changes planned in the sprint, providing an easy mechanism for granting all of the "Get" privileges (e.g., an out-of-the-box role), creating some conventions for handling application-level permissions, and having improved tools for troubleshooting privilege problems should go a long way in improving the situation without having to completely disable any API-level security.

-Burke

On Fri, May 18, 2012 at 11:52 AM, Mark Goodrich <[hidden email]> wrote:
+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: [hidden email] [[hidden email]] On Behalf Of Michael Seaton [[hidden email]]
Sent: Friday, May 18, 2012 11:27 AM
To: [hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Mark Goodrich [[hidden email]]
Sent: Friday, May 18, 2012 10:49 AM
To: [hidden email]
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:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



[hidden email] from OpenMRS Developers' mailing list

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: [hidden email]
Unsubscribe: [hidden email]
[hidden email] from OpenMRS Developers' mailing list
Loading...