Daniel is the mentor for that project, and Goutham is the student, so they should comment on whether the project will cover viewing/editing forms.
-Darius On Mon, May 14, 2012 at 5:21 AM, 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 > _________________________________________ 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]
