Roles and Privileges Sprint

classic Classic list List threaded Threaded
19 messages Options
Daniel Kayiwa-2 Daniel Kayiwa-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Roles and Privileges Sprint

Greetings to you all!!!


We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:


1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles


Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?


All questions, comments and suggestions are very welcome!!!


Daniel Kayiwa

On Behalf of the OpenMRS Community



--
The greatest want of the world is the want of men—men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall. 

[hidden email] from OpenMRS Implementers' mailing list
James Arbaugh James Arbaugh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

About filtering things by roles...

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:
  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does
If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

-Darius

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

And how does  this connect with the idea of separating privileges between api and web layer?  Or the idea of separating "use" from "view"?  Seems like what people want really requires a core level change. 

 

Are we letting the idea of organizing around sprints push us to do module-implementable changes instead of designing?  I think web services could use another sprint before 1.0, too much is being put off until 1.1.  Also, the new attribute paradigm is not completely implemented; multi-valued attributes are not supported.  Not to mention whether 1 bug swim lane is sufficient.  Or whether we need to be more test-driven in development and have a functional test capability so that we can have competent releases sooner.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Ali-IRD Ali-IRD
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Hi all,

It would be great if time could be spent on modernizing the restrict by role module. We have a potential project where users would like to be able to restrict who can view or edit a given patient. For them this ability is key for reasons of patient privacy so it would be brilliant if some cycles could be spent on this.

Ali

On May 11, 2012 4:52 PM, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <[hidden email]> wrote:

And how does  this connect with the idea of separating privileges between api and web layer?  Or the idea of separating "use" from "view"?  Seems like what people want really requires a core level change. 

 

Are we letting the idea of organizing around sprints push us to do module-implementable changes instead of designing?  I think web services could use another sprint before 1.0, too much is being put off until 1.1.  Also, the new attribute paradigm is not completely implemented; multi-valued attributes are not supported.  Not to mention whether 1 bug swim lane is sufficient.  Or whether we need to be more test-driven in development and have a functional test capability so that we can have competent releases sooner.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list

[hidden email] from OpenMRS Implementers' mailing list
James Arbaugh James Arbaugh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

In reply to this post by Darius Jazayeri-3

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Daniel is the mentor for that project, and Goutham is the student, so they should comment on whether the project will cover viewing/editing forms.

-Darius

On Mon, May 14, 2012 at 5:21 AM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Bob Jolliffe Bob Jolliffe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

A thought on restricting access to patient data using restrict by role
or restrict by encounter:

Whereas we (computer scientists) tend to view privacy in absolute
terms, health care providers do not necessarily view things the same
way.  There will always be legitimate reasons why a doctor or nurse
may need temporary access to another doctor/nurse's patient's data.
Its important in our well-meaning scheming that we don't lock out
these legitimate requests.  You security gurus will know better, but
there is an approach called Optimistic Access Control which works on
the assumption that the intent of the user is generally good.
Whatever scheme is in place, the system should provide a feature to
"break the glass" to gain access to data she might not otherwise have
access to.  The important thing about OAC is that (i) the user is
warned that she is attempting to override her permissions and (ii)
that there is a clear audit trail and alerting mechanism.

I'm not sure how relevant this is to the upcoming sprint, but if there
is discussion around schemes over and above role based access, I think
it might be useful to consider this approach.

Bob

On 14 May 2012 15:14, Darius Jazayeri <[hidden email]> wrote:

> Daniel is the mentor for that project, and Goutham is the student, so they
> should comment on whether the project will cover viewing/editing forms.
>
> -Darius
>
>
> On Mon, May 14, 2012 at 5:21 AM, James Arbaugh <[hidden email]>
> wrote:
>>
>> Hi Darius,
>>
>>
>>
>> Thanks for setting me straight.  I confused the “Restrict By Role Module”
>> with the “Restrict By Encounter Type Module” by the HISP India group which
>> would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role
>> Module”.
>>
>>
>>
>> I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on
>> Dashboard Design Page because it’s related. The GSoC main project is to
>> limit which forms appear in the list of forms that can be filled out.
>> TRUNK-1640 is to limit which role is required for given encounter types to
>> be viewed/edited.
>> https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module
>>
>> Roles Based Form Display
>>
>> On the form designer, roles can be associated with forms. Roles associated
>> with a form can either be associated as a "View" role or an "Edit" role (or
>> the equivalent "Both" role). On the patient dashboard, if there are roles
>> associated with a form, then the currently authenticated user must have the
>> appropriate roles to view and/or edit a form.
>>
>> Can we make TRUNK-1640 an official requirement for the GSoC project?  Or
>> is that something that can be addressed through the Roles and Privileges
>> Sprint?
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Darius Jazayeri
>>
>>
>> Sent: Thursday, May 10, 2012 7:19 PM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint
>>
>>
>>
>> About filtering things by roles...
>>
>>
>>
>> Filtering forms by roles and patient characteristics is a GSoC project
>> this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi)
>> so we will not be working on that during the sprint. (But yes, we know it's
>> highly voted and much awaited!)
>>
>>
>>
>> The Restrict By Role module allows you to use Cohort Builder queries to
>> limit the patients a given Role can see. As far as I know, this is the only
>> published module that lets you limit the patients that particular users are
>> allowed to see, although that's a frequently-requested feature. This was a
>> very early module (from 2007), so the code is mediocre, it probably slows
>> down your patient searches a lot, and the API has changed since then so it
>> probably misses a lot of restrictions.
>>
>>
>>
>> [The reason there aren't any other published modules doing this is that
>> it's basically impossible to solve the problem generically in a performant
>> way.)
>>
>>
>>
>> So the question is: are there any implementers out there who would like to
>> see us spend some developer cycles doing a modernized version of Restrict By
>> Role? It would:
>>
>> let you restrict the patients that particular users/roles can see based on
>> reporting module cohort queries (instead of cohort builder)
>> cache query results so it slows things down less than the current module
>> does
>>
>> If there's interest, we can spend some cycles on this during the sprint.
>> (And if not, not.)
>>
>>
>>
>> -Darius
>>
>>
>>
>> On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]>
>> wrote:
>>
>> Greetings all!
>>
>>
>>
>> One of our highest priorities should be the RestrictByRole module
>> capability; the ability to specify which user roles can view/edit which
>> encounters.  This is important to many based on the number of people that
>> have voted (6) for the “Add roles-based form display feature ticket”…
>>
>> https://tickets.openmrs.org/browse/TRUNK-1640
>>
>> …which includes the ability to “filter form viewing and editing based on
>> roles”.
>>
>>
>>
>> This is also something that comes up frequently on the mailing list and on
>> OpenMRS Answers.
>>
>>
>> https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms
>>
>>
>>
>> +1 on improving documentation
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Daniel Kayiwa
>> Sent: Thursday, May 10, 2012 5:22 PM
>> To: [hidden email]
>> Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint
>>
>>
>>
>> Greetings to you all!!!
>>
>>
>>
>> We are soon going to have a sprint on roles and privileges, during which
>> we are thinking of dealing with the following topics:
>>
>>
>>
>> 1) Make it easy for an admin to see what privileges are needed to perform
>> a sequence of actions.
>>
>> 2) Improve the page a user sees when they fail a privilege check.
>>
>> 3) Improve documentation on how to use privileges/roles and avoid
>> pitfalls.
>>
>> 4) Implement Organizational Role as designed in this wiki page:
>> https://wiki.openmrs.org/display/docs/Organizational+Roles
>>
>>
>>
>> Do you feel the above topics address what the community needs, as far as
>> roles and privileges are concerned?
>>
>> Does anyone want a modernized version of the Restrict By Role module?
>>
>> Do you have anything to say about the Organizational Role API design?
>>
>>
>>
>> All questions, comments and suggestions are very welcome!!!
>>
>>
>>
>> Daniel Kayiwa
>>
>> On Behalf of the OpenMRS Community
>>
>>
>>
>> ________________________________
>>
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>>
>>
>>
>> ________________________________
>>
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>>
>> ________________________________
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Implementers' mailing list

_________________________________________

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

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

Re: Roles and Privileges Sprint

Thanks for this, Bob.  Well said.  Auditing access (i.e., accountability) is the foundation, then restriction (with "glass-breaking" override when the computer is wrong) can help make it easiest for users to do the right thing, while holding them accountable if/when they do not.

-Burke

On Mon, May 14, 2012 at 10:28 AM, Bob Jolliffe <[hidden email]> wrote:
A thought on restricting access to patient data using restrict by role
or restrict by encounter:

Whereas we (computer scientists) tend to view privacy in absolute
terms, health care providers do not necessarily view things the same
way.  There will always be legitimate reasons why a doctor or nurse
may need temporary access to another doctor/nurse's patient's data.
Its important in our well-meaning scheming that we don't lock out
these legitimate requests.  You security gurus will know better, but
there is an approach called Optimistic Access Control which works on
the assumption that the intent of the user is generally good.
Whatever scheme is in place, the system should provide a feature to
"break the glass" to gain access to data she might not otherwise have
access to.  The important thing about OAC is that (i) the user is
warned that she is attempting to override her permissions and (ii)
that there is a clear audit trail and alerting mechanism.

I'm not sure how relevant this is to the upcoming sprint, but if there
is discussion around schemes over and above role based access, I think
it might be useful to consider this approach.

Bob

On 14 May 2012 15:14, Darius Jazayeri <[hidden email]> wrote:
> Daniel is the mentor for that project, and Goutham is the student, so they
> should comment on whether the project will cover viewing/editing forms.
>
> -Darius
>
>
> On Mon, May 14, 2012 at 5:21 AM, James Arbaugh <[hidden email]>
> wrote:
>>
>> Hi Darius,
>>
>>
>>
>> Thanks for setting me straight.  I confused the “Restrict By Role Module”
>> with the “Restrict By Encounter Type Module” by the HISP India group which
>> would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role
>> Module”.
>>
>>
>>
>> I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on
>> Dashboard Design Page because it’s related. The GSoC main project is to
>> limit which forms appear in the list of forms that can be filled out.
>> TRUNK-1640 is to limit which role is required for given encounter types to
>> be viewed/edited.
>> https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module
>>
>> Roles Based Form Display
>>
>> On the form designer, roles can be associated with forms. Roles associated
>> with a form can either be associated as a "View" role or an "Edit" role (or
>> the equivalent "Both" role). On the patient dashboard, if there are roles
>> associated with a form, then the currently authenticated user must have the
>> appropriate roles to view and/or edit a form.
>>
>> Can we make TRUNK-1640 an official requirement for the GSoC project?  Or
>> is that something that can be addressed through the Roles and Privileges
>> Sprint?
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Darius Jazayeri
>>
>>
>> Sent: Thursday, May 10, 2012 7:19 PM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint
>>
>>
>>
>> About filtering things by roles...
>>
>>
>>
>> Filtering forms by roles and patient characteristics is a GSoC project
>> this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi)
>> so we will not be working on that during the sprint. (But yes, we know it's
>> highly voted and much awaited!)
>>
>>
>>
>> The Restrict By Role module allows you to use Cohort Builder queries to
>> limit the patients a given Role can see. As far as I know, this is the only
>> published module that lets you limit the patients that particular users are
>> allowed to see, although that's a frequently-requested feature. This was a
>> very early module (from 2007), so the code is mediocre, it probably slows
>> down your patient searches a lot, and the API has changed since then so it
>> probably misses a lot of restrictions.
>>
>>
>>
>> [The reason there aren't any other published modules doing this is that
>> it's basically impossible to solve the problem generically in a performant
>> way.)
>>
>>
>>
>> So the question is: are there any implementers out there who would like to
>> see us spend some developer cycles doing a modernized version of Restrict By
>> Role? It would:
>>
>> let you restrict the patients that particular users/roles can see based on
>> reporting module cohort queries (instead of cohort builder)
>> cache query results so it slows things down less than the current module
>> does
>>
>> If there's interest, we can spend some cycles on this during the sprint.
>> (And if not, not.)
>>
>>
>>
>> -Darius
>>
>>
>>
>> On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]>
>> wrote:
>>
>> Greetings all!
>>
>>
>>
>> One of our highest priorities should be the RestrictByRole module
>> capability; the ability to specify which user roles can view/edit which
>> encounters.  This is important to many based on the number of people that
>> have voted (6) for the “Add roles-based form display feature ticket”…
>>
>> https://tickets.openmrs.org/browse/TRUNK-1640
>>
>> …which includes the ability to “filter form viewing and editing based on
>> roles”.
>>
>>
>>
>> This is also something that comes up frequently on the mailing list and on
>> OpenMRS Answers.
>>
>>
>> https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms
>>
>>
>>
>> +1 on improving documentation
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Daniel Kayiwa
>> Sent: Thursday, May 10, 2012 5:22 PM
>> To: [hidden email]
>> Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint
>>
>>
>>
>> Greetings to you all!!!
>>
>>
>>
>> We are soon going to have a sprint on roles and privileges, during which
>> we are thinking of dealing with the following topics:
>>
>>
>>
>> 1) Make it easy for an admin to see what privileges are needed to perform
>> a sequence of actions.
>>
>> 2) Improve the page a user sees when they fail a privilege check.
>>
>> 3) Improve documentation on how to use privileges/roles and avoid
>> pitfalls.
>>
>> 4) Implement Organizational Role as designed in this wiki page:
>> https://wiki.openmrs.org/display/docs/Organizational+Roles
>>
>>
>>
>> Do you feel the above topics address what the community needs, as far as
>> roles and privileges are concerned?
>>
>> Does anyone want a modernized version of the Restrict By Role module?
>>
>> Do you have anything to say about the Organizational Role API design?
>>
>>
>>
>> All questions, comments and suggestions are very welcome!!!
>>
>>
>>
>> Daniel Kayiwa
>>
>> On Behalf of the OpenMRS Community
>>
>>
>>
>> ________________________________
>>
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>>
>>
>>
>> ________________________________
>>
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>>
>> ________________________________
>> Click here to unsubscribe from OpenMRS Implementers' mailing list
>
>
> ________________________________
> Click here to unsubscribe from OpenMRS Implementers' mailing list

_________________________________________

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

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



[hidden email] from OpenMRS Implementers' mailing list
Daniel Kayiwa Daniel Kayiwa
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

In reply to this post by James Arbaugh

Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?


On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

[hidden email] from OpenMRS Implementers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

Ben

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:

Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?



On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Hi Implementers and Devs,

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)


-Darius

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:
Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

Ben


On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:

Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?



On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
James Arbaugh James Arbaugh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?



On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

(Sending to the dev list, since my reply is more dev-focused.)

This makes a lot of sense to me, both as a use case, and as a way to approach it.

At first thought, it seems to me that the following would be pretty easy to implement:
  • Add two properties to EncounterType: viewPrivilege and editPrivilege
  • in the db those would be encounter_type.view_privilege and edit_privilege (varchar references privilege)
  • The encounters dashboard tab would need to respect viewPrivilege when deciding what encounters to display
    • can we build this into the paged hibernate query we're using, though?
  • Same goes for the visits dashboard tab
  • Same goes for the encounter search widget, and the manage encounters admin page
Assuming the hibernate query is tractable, and assuming people generally agree with this design, I could see this fitting into the sprint...

-Darius

On Thu, May 17, 2012 at 1:52 PM, James Arbaugh <[hidden email]> wrote:

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM


To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?



On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

In reply to this post by James Arbaugh

Re persons without privileges not seeing encounters: What do you think is better, that the encounter info appear on the dashboard but disabled (greyed), or that it not appear at all?  I can imagine a doctor using somebody else's terminal and not seeing an encounter he knows exists and losing faith in the system.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Arbaugh
Sent: Thursday, May 17, 2012 4:53 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [hidden email] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?

 

On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  <a href="https://wiki.openmrs.org/display/docs/Jembi&#43;Html&#43;Form&#43;Entry&#43;Module" target="_blank"> https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Hannan, Terry J Hannan, Terry J
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint-encounters

As a physician to see all the encounters is critical for the longitudinal knowledge of the patient's 'history'. That is, it is an event. What is meant by making it disabled? What is being disabled? The data should remain as entered/acquired. 
Terry Hannan 
Sent from my iPad

On 18/05/2012, at 9:17 PM, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <[hidden email]> wrote:

Re persons without privileges not seeing encounters: What do you think is better, that the encounter info appear on the dashboard but disabled (greyed), or that it not appear at all?  I can imagine a doctor using somebody else's terminal and not seeing an encounter he knows exists and losing faith in the system.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Arbaugh
Sent: Thursday, May 17, 2012 4:53 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [hidden email] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?

 

On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list

Want to Get Healthy?

The Tasmanian Government's Get Healthy Information and Coaching Service(R) provides free information and coaching support to Tasmanian adults who would like to learn healthier eating habits, be more active or achieve and maintain a healthy weight. Call 1300 806 258 between 8am and 8pm, Monday to Friday or visit www.gethealthy.tas.gov.au for more information.
"

CONFIDENTIALITY NOTICE AND DISCLAIMER

The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

If the transmission contains advice, the advice is based on instructions in relation to, and is provided to the addressee in connection with, the matter mentioned above. Responsibility is not accepted for reliance upon it by any other person or for any other purpose.

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

Re: Roles and Privileges Sprint-encounters

We've had these discussions recently as part of an ethics project, trying to empower patients to control access to their data in an ethical and safe manner.  Hiding parts of clinical data from a clinician can adversely effect their ability to provide proper care.  Patients do this all of the time by deciding what to tell their doctor and, at times, may jeopardize their care in the process... but that's their choice.   Hiding parts of known data in the EMR without the provider knowing it is being hidden can be equally dangerous.

We decided that it is better to let the provider know that they are only seeing part of the data, so they can at least know that they are not seeing everything.  In some cases, this is straightforward -- e.g., our system in Regenstrief will hide mental health notes from many providers.  You can see a visit occurred, but not the note.  If you selectively mask certain data, then a malicious user can sometimes infer the content by applying different search filters (search for "gonorrhea positive" and a masked result shows up, search for "gonorrhea negative" and it the masked result does not show up).

I would recommend being very careful on masking data and, when you do so, let the provider know that data are being masked -- e.g., showing "You do not have privileges to see this encounter" in place of a masked encounter.  Then use auditing & accountability as your primary means of securing data.  When a user accesses data they should not, confront them and, if they do not have a good reason, punish them appropriately.  Most providers & patients are trying to do the right thing.

Cheers,

-Burke

On Friday, May 18, 2012, Hannan, Terry J wrote:
As a physician to see all the encounters is critical for the longitudinal knowledge of the patient's 'history'. That is, it is an event. What is meant by making it disabled? What is being disabled? The data should remain as entered/acquired. 
Terry Hannan 
Sent from my iPad

On 18/05/2012, at 9:17 PM, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <[hidden email]> wrote:

Re persons without privileges not seeing encounters: What do you think is better, that the encounter info appear on the dashboard but disabled (greyed), or that it not appear at all?  I can imagine a doctor using somebody else's terminal and not seeing an encounter he knows exists and losing faith in the system.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Arbaugh
Sent: Thursday, May 17, 2012 4:53 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?

 

On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 


[hidden email] from OpenMRS Implementers' mailing list
Jonathan Galingan Jonathan Galingan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

In reply to this post by Friedman, Roger (CDC/CGH/DGHA) (CTR)
I think it should not appear at all. Some forms, if they exist in a patients chart, imply that a patient is enrolled in a program or is a suspect for some kind of disease.  

On Fri, May 18, 2012 at 6:59 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Re persons without privileges not seeing encounters: What do you think is better, that the encounter info appear on the dashboard but disabled (greyed), or that it not appear at all?  I can imagine a doctor using somebody else's terminal and not seeing an encounter he knows exists and losing faith in the system.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Arbaugh
Sent: Thursday, May 17, 2012 4:53 PM


To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

 

From: [hidden email] [hidden email] On Behalf Of Darius Jazayeri
Sent: Wednesday, May 16, 2012 7:09 PM
To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi Implementers and Devs,

 

James has been pushing for TRUNK-1640 to be included in next week's sprint (and I don't blame him--it has 6 votes!). But on today's design call, we looked at the proposed solution in that ticket, and we're not comfortable introducing it into the codebase with the given design.

 

In particular, it wants to create a form_role table that links forms to the roles that are allowed to enter/edit them.

 

Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. Instead we would add a form.entry_privilege column, so a sysadmin can create a privilege for entering a particular form, and assign it to whatever role or roles they choose.

 

James & others: would this solve your use case? If possible please comment on the ticket. (I'm emailing this to both the implementers and dev lists, so you won't all necessarily get each others replies.)

 

 

-Darius

 

On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[hidden email]> wrote:

Looking at it briefly TRUNK-1640 looks very similar to what is on slate for the gsoc project. Both are linked to forms, not to encounter types.  

 

Ben

 

On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[hidden email]> wrote:


Hi James,

We shall not deal with TRUNK-1640 during GSOC because it will broaden the scope more than what the student is expected to cover in that limited time.

However, i see it fitting in next week's Roles and Privileges Sprint.
So i think we could consider it as part of what we are going to deal with during that sprint.

What do others think?

 

On Mon, May 14, 2012 at 3:21 PM, James Arbaugh <[hidden email]> wrote:

Hi Darius,

 

Thanks for setting me straight.  I confused the “Restrict By Role Module” with the “Restrict By Encounter Type Module” by the HISP India group which would address the needs of TRUNK-1640.  We do NOT need the “Restrict By Role Module”.

 

I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on Dashboard Design Page because it’s related. The GSoC main project is to limit which forms appear in the list of forms that can be filled out.  TRUNK-1640 is to limit which role is required for given encounter types to be viewed/edited.  https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module

Roles Based Form Display

On the form designer, roles can be associated with forms. Roles associated with a form can either be associated as a "View" role or an "Edit" role (or the equivalent "Both" role). On the patient dashboard, if there are roles associated with a form, then the currently authenticated user must have the appropriate roles to view and/or edit a form.

Can we make TRUNK-1640 an official requirement for the GSoC project?  Or is that something that can be addressed through the Roles and Privileges Sprint?

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri


Sent: Thursday, May 10, 2012 7:19 PM
To: [hidden email]

Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

About filtering things by roles...

 

Filtering forms by roles and patient characteristics is a GSoC project this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) so we will not be working on that during the sprint. (But yes, we know it's highly voted and much awaited!)

 

The Restrict By Role module allows you to use Cohort Builder queries to limit the patients a given Role can see. As far as I know, this is the only published module that lets you limit the patients that particular users are allowed to see, although that's a frequently-requested feature. This was a very early module (from 2007), so the code is mediocre, it probably slows down your patient searches a lot, and the API has changed since then so it probably misses a lot of restrictions.

 

[The reason there aren't any other published modules doing this is that it's basically impossible to solve the problem generically in a performant way.)

 

So the question is: are there any implementers out there who would like to see us spend some developer cycles doing a modernized version of Restrict By Role? It would:

  • let you restrict the patients that particular users/roles can see based on reporting module cohort queries (instead of cohort builder)
  • cache query results so it slows things down less than the current module does

If there's interest, we can spend some cycles on this during the sprint. (And if not, not.)

 

-Darius

 

On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[hidden email]> wrote:

Greetings all! 

 

One of our highest priorities should be the RestrictByRole module capability; the ability to specify which user roles can view/edit which encounters.  This is important to many based on the number of people that have voted (6) for the “Add roles-based form display feature ticket”…

https://tickets.openmrs.org/browse/TRUNK-1640

…which includes the ability to “filter form viewing and editing based on roles”.

 

This is also something that comes up frequently on the mailing list and on OpenMRS Answers.

https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms

 

+1 on improving documentation

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Greetings to you all!!!

 

We are soon going to have a sprint on roles and privileges, during which we are thinking of dealing with the following topics:

 

1) Make it easy for an admin to see what privileges are needed to perform a sequence of actions. 

2) Improve the page a user sees when they fail a privilege check.

3) Improve documentation on how to use privileges/roles and avoid pitfalls.

4) Implement Organizational Role as designed in this wiki page: https://wiki.openmrs.org/display/docs/Organizational+Roles

 

Do you feel the above topics address what the community needs, as far as roles and privileges are concerned?

Does anyone want a modernized version of the Restrict By Role module?

Do you have anything to say about the Organizational Role API design?

 

All questions, comments and suggestions are very welcome!!!

 

Daniel Kayiwa

On Behalf of the OpenMRS Community

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
Jonathan D. Galingan, MD
Project Manager for Computerization
Philippine General Hospital


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

Re: Roles and Privileges Sprint

Completely omitting data can have adverse effects as well.  If you are going to completely hide encounters, be sure that they cannot contain information that would alter care; otherwise, providers may make incorrect assumptions and potentially harm the patient.  An alternative is to let the provider know that you are concealing information (without displaying the form name), so the provider is at least aware that they are working with partial information. 

If providers aren't directly using the system, then it's less of a concern.  Any patient summaries or other tools used by providers that go directly to observations will bypass these filters.

-Burke

On Saturday, May 19, 2012, Jonathan Galingan wrote:
I think it should not appear at all. Some forms, if they exist in a patients chart, imply that a patient is enrolled in a program or is a suspect for some kind of disease.  

On Fri, May 18, 2012 at 6:59 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Re persons without privileges not seeing encounters: What do you think is better, that the encounter info appear on the dashboard but disabled (greyed), or that it not appear at all?  I can imagine a doctor using somebody else's terminal and not seeing an encounter he knows exists and losing faith in the system.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Arbaugh
Sent: Thursday, May 17, 2012 4:53 PM


To: [hidden email]
Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Hi All!

 

I have commented on TRUNK-3361 and had a short call with Darius to explain the use-case that we are trying to solve.  It has more to do with requiring permissions for viewing/editing encounters than it does to what users can fill out a given form. So, after a form has already been filled out (which we’ll called an encounter at that point and is shown under the encounter/visit tab on the dashboard).  Who has permissions to view it and/or edit it?  So for example, we need to limit the viewing/editing of Blood Bank  encounters to only users of the Blood Bank.  And we need to limit the editing of Lab encounters to only Lab Technicians, but they can be viewable by doctors.  And we need to limit the editing of surgery encounters by Surgery data entry clerks and surgeons, but all doctors can view them.  If a user isn’t going to be able to view/edit the contents then it need not appear in the list of encounters.

 

The view and edit role and/or privileges could be implemented on the Edit Encounter Type page rather than on the Edit Form page.  The consideration of doing it on the Edit Form page instead would be if someone needed to limit viewing/editing of forms in the case of different forms that use the same type of encounter.

 

Thanks for your patience and willingness to help make this needed functionality a reality.

 

Thanks,

James

--
Jonathan D. Galingan, MD
Project Manager for Computerization
Philippine General Hospital


<a href="javascript:_e({}, &#39;cvml&#39;, &#39;LISTSERV@LISTSERV.IUPUI.EDU?body\x3dSIGNOFF%20openmrs-implement-l&#39;);" target="_blank">Click here to unsubscribe from OpenMRS Implementers' mailing list

[hidden email] from OpenMRS Implementers' mailing list
Loading...