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
>

_________________________________________

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]

Reply via email to