Roles and Privileges Sprint

classic Classic list List threaded Threaded
11 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 Developers' mailing list
Sateesh Babu Sateesh Babu
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roles and Privileges Sprint

Can implementing the corresponding REST API's be made part of the same sprint. I see that there is a separate activity going on to define the REST API, but it would be good to consider the REST part with the functional part, like here related to the roles/privileges

--
Sateesh

On Fri, May 11, 2012 at 2:52 AM, Daniel Kayiwa <[hidden email]> wrote:
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 Developers' mailing list


[hidden email] from OpenMRS Developers' 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 Daniel Kayiwa-2

I don't think it's a good idea to have a separate organizational role table, and I don't think this proposal has been thought through thoroughly.

 

I'd like to review some of the discussion that took place last spring around the HR module.  At that time, what was on the table was the separation of organizational roles from privileges by breaking the link between users and providers.  At that time, I proposed that the distinction be between staff and users, and intended to use the providers table as a staff table.  However, this was strongly opposed by Burke and others on the grounds that providers were only those who provided services to patients and that other staff should be excluded.  I was told that the use of the providers table for other staff would not be welcome, and the HR module was developed with different core table, staff, linked to person.

 

As I read the wiki page, the proposal addresses several issues:

 

* People are still confusing organizational roles with system privileges.  This problem has already been solved by the split between user and provider, an organizational role provider attribute would suffice to handle issues such as the letters going out with the wrong signature.

 

* There are functional distinctions between providers of the same provider type which should be available for selecting pick lists.  This can also be addressed by provider attributes or tags/categories. 

 

* People are being miscategorized for administrative reporting (doctors/PAs/nurses).  During the HR discussion, the point was made repeatedly that administrative reporting was outside the scope of an EMR.  To the extent that a provider attribute would not suffice, this should bring the whole issue of the role of OpenMRS in administrative reporting back into play.

 

* People have different organizational roles at different locations.  This issue is addressed only in the data model by having a location attribute; it is not addressed in the text.  I can imagine the following possible uses: it is intended to be used for location-based data access privileges (reconflating organizational role and user privilege); it is intended to be used for location-based limitations on pick lists; it is intended to make organizational reporting more useful.  If it is the third use that is motivating the change, and administrative reporting is on the table, then I would urge people to take a look at the data model for the HR module (hr3.mwb (mysql workbench) on the HR module project page).  There, the issue is dealt with more generally (based on multi-country requirements analysis) with the concepts of post and assignment: the post is the official job title and the organizational unit of which the staff is a member, while an assignment is an organizational role; there can be multiple assignments per post, so the same staff can work as a PA at location 1 on Monday and a CHW at location 2 on Tuesday.

 

   

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Kayiwa
Sent: Thursday, May 10, 2012 5:22 PM
To: [hidden email]
Subject: [OPENMRS-DEV] 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 Developers' mailing list


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

Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

In reply to this post by Daniel Kayiwa-2

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 Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [OPENMRS-IMPLEMENTERS] 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 Developers' 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: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

Darius --

     Wouldn't it make sense at the same time to make privilege a standard OpenMRS data object?  At present, it does not have an integer id field or audit info.

Saludos, Roger

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 17, 2012 5:24 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] 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.  <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 Developers' mailing list


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

Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

The design sounds good to me.

Roger, the solution might be to have a "X number of encounters are hidden" shown on some screens.  Or would that be giving away too much information?

I don't think we should muddle in adding a privilege.id with this.  If desired, that can be a later refactoring. (My vote will be that its not needed though)

Ben

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

Darius --

     Wouldn't it make sense at the same time to make privilege a standard OpenMRS data object?  At present, it does not have an integer id field or audit info.

Saludos, Roger

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 17, 2012 5:24 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] 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 Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


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

Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

Burke did not want us to add privilege.ID because the privilege name _is_ the primary key in a business sense. And because they are referred to by name in code.

-Darius (by phone)

On May 18, 2012 6:15 AM, "Ben Wolfe" <[hidden email]> wrote:
The design sounds good to me.

Roger, the solution might be to have a "X number of encounters are hidden" shown on some screens.  Or would that be giving away too much information?

I don't think we should muddle in adding a privilege.id with this.  If desired, that can be a later refactoring. (My vote will be that its not needed though)

Ben

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

Darius --

     Wouldn't it make sense at the same time to make privilege a standard OpenMRS data object?  At present, it does not have an integer id field or audit info.

Saludos, Roger

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 17, 2012 5:24 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] 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 Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' 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: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

Yes, but now we would be adding 2 varchar fields to each encounter type.  And how’d you like the way things turned out with globalproperty under the same logic?

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Friday, May 18, 2012 5:34 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

 

Burke did not want us to add privilege.ID because the privilege name _is_ the primary key in a business sense. And because they are referred to by name in code.

-Darius (by phone)

On May 18, 2012 6:15 AM, "Ben Wolfe" <[hidden email]> wrote:

The design sounds good to me.

Roger, the solution might be to have a "X number of encounters are hidden" shown on some screens.  Or would that be giving away too much information?

I don't think we should muddle in adding a privilege.id with this.  If desired, that can be a later refactoring. (My vote will be that its not needed though)

Ben

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

Darius --

     Wouldn't it make sense at the same time to make privilege a standard OpenMRS data object?  At present, it does not have an integer id field or audit info.

Saludos, Roger

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 17, 2012 5:24 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] 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.  <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 Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


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

Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint

We already have person_attribute_type.edit_privilege, so we have a precedent.  I am satisfied with how GP turned out. :-)

Ben

On Sat, May 19, 2012 at 4:32 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Yes, but now we would be adding 2 varchar fields to each encounter type.  And how’d you like the way things turned out with globalproperty under the same logic?

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Friday, May 18, 2012 5:34 PM


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

 

Burke did not want us to add privilege.ID because the privilege name _is_ the primary key in a business sense. And because they are referred to by name in code.

-Darius (by phone)

On May 18, 2012 6:15 AM, "Ben Wolfe" <[hidden email]> wrote:

The design sounds good to me.

Roger, the solution might be to have a "X number of encounters are hidden" shown on some screens.  Or would that be giving away too much information?

I don't think we should muddle in adding a privilege.id with this.  If desired, that can be a later refactoring. (My vote will be that its not needed though)

Ben

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

Darius --

     Wouldn't it make sense at the same time to make privilege a standard OpenMRS data object?  At present, it does not have an integer id field or audit info.

Saludos, Roger

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Thursday, May 17, 2012 5:24 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] 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 Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


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