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<mailto: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>
[mailto: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<mailto: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<mailto: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<mailto: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<mailto: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>
[mailto: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<mailto: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<mailto: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>
[mailto: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<mailto: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<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto: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<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
________________________________
Click here to
unsubscribe<mailto: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]
