(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
>
_________________________________________
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]
