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" <b...@openmrs.org> 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) < > r...@cdc.gov> 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:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Darius >> Jazayeri >> *Sent:* Thursday, May 17, 2012 5:24 PM >> *To:* openmrs-deve...@listserv.iupui.edu >> *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 <jarba...@hashaiti.org> >> wrote:**** >> >> 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:* implement...@openmrs.org [mailto:implement...@openmrs.org] *On >> Behalf Of *Darius Jazayeri >> *Sent:* Wednesday, May 16, 2012 7:09 PM**** >> >> >> *To:* openmrs-implemen...@listserv.iupui.edu >> *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 <b...@openmrs.org> 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 <kayiwadan...@gmail.com> >> 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 <jarba...@hashaiti.org> >> 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:* implement...@openmrs.org [mailto:implement...@openmrs.org] *On >> Behalf Of *Darius Jazayeri**** >> >> >> *Sent:* Thursday, May 10, 2012 7:19 PM >> *To:* openmrs-implemen...@listserv.iupui.edu**** >> >> *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 <jarba...@hashaiti.org> >> 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:* implement...@openmrs.org [mailto:implement...@openmrs.org] *On >> Behalf Of *Daniel Kayiwa >> *Sent:* Thursday, May 10, 2012 5:22 PM >> *To:* openmrs-implemen...@listserv.iupui.edu >> *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<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?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<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
