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-to-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<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >>> **** >>> >>> ** ** >>> ------------------------------ >>> >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >>> **** >>> ------------------------------ >>> Click here to >>> unsubscribe<[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<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[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]
