Hi All!
I have commented on TRUNK-3361 <https://tickets.openmrs.org/browse/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: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Wednesday, May 16, 2012 7:09 PM To: [email protected] 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 <https://tickets.openmrs.org/browse/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.) https://tickets.openmrs.org/browse/TRUNK-3361 -Darius On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Thursday, May 10, 2012 7:19 PM To: [email protected] 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 <https://modules.openmrs.org/modules/view.jsp?module=restrictbyrole> 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 <[email protected]> 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-t o-specific-form-entry-forms +1 on improving documentation Thanks, James From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Kayiwa Sent: Thursday, May 10, 2012 5:22 PM To: [email protected] 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 <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list ________________________________ Click here to unsubscribe <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list ________________________________ Click here to unsubscribe <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> 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. ________________________________ Click here to unsubscribe <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list ________________________________ Click here to unsubscribe <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list ________________________________ Click here to unsubscribe <mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
