just FYI, as a resource, the researchencounters module has this functionality as well. Check out the global properties:
http://svn.openmrs.org/openmrs-modules/researchencounters/metadata/config.xml d On Fri, Apr 13, 2012 at 8:04 AM, Mark Goodrich <[email protected]> wrote: > Mathias-- > > Yes, what Darius is suggesting is to take the changes and move them into a > module. (I can't comment on the feasibility of this because I haven't > looked at the changes). > > The downside of modifying the Jembi module is that then you'd be running a > custom version of Html Form Entry... there have been many bug fixes and new > features added to Html Form Entry since Jembi branched from the Html Form > Entry trunk, and so you'd be on your own supporting the Jembi HTML Form > Entry module. > > If you use the regular Html Form Entry module you would benefit from the > recent bug fixes, as well as the support of the community if you run into > questions/bugs. You would, however, most likely be supporting the > TRUNK-1640-patch-as-a-module on your own. > > I can't comment too much on the tradeoff off support/development time on > your end without looking into the code a little more, but my gut would be > create a module to do what you need to do and use the standard Html Form > Entry module. Then, all going well, at some point in the near future core > will support restricting forms by roles and you won't have to use the > custom module you build anymore. > > Hope this helps... > > Take care, > Mark > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Mathias Lin | > Meta Healthcare > Sent: Thursday, April 12, 2012 10:44 PM > To: [email protected] > Subject: Re: [OPENMRS-DEV] Fwd: Regarding ticket TRUNK-1640: Add > roles-based form display feature > > Hi Darius, > > ok. > Actually I was planning to go ahead with the Jembi module and modify that, > as it's already complete, just not for the latest OpenMRS version, and > adjust it accordingly; since only Html Forms are needed at the moment and > it's just a quick fix anyway. I guess it would less cumbersome than > finishing the 10% of the core patch. Maybe not? > > > Advantages: > > You can write the module to target the OpenMRS version relevant to > > your implementation needs, and deploy it quickly. > > Isn't it (the code attached to the ticket) a *core* patch rather than a > module? > > - Mathias > > > > On Fri, Apr 13, 2012 at 1:00 AM, Darius Jazayeri <[email protected]> > wrote: > > Looking back through the whole conversation on TRUNK-1640, the ticket > > was almost complete. I summarized the remaining TODOs in my comment > > from 2010-12-10 00:56:34 EST. > > > > However at this point we're planning to do a more sophisticated > > implementation of this functionality in this GSoC project. To me it > > seems like the implication is that we're no longer going to apply the > > patch from > > TRUNK-1640 to core. (It would be helpful if Daniel/Ben can comment on > > their plans for the GSoC project.) > > > > Mathias, I suggest you consider taking the almost-complete patch from > > the ticket, and package it up as a module. > > > > Advantages: > > > > No dependency on the GSoC project's timeline, especially if you just > > need minimal functionality You can write the module to target the > > OpenMRS version relevant to your implementation needs, and deploy it > > quickly. > > > > -Darius > > > > On Thu, Apr 12, 2012 at 9:33 AM, Mark Goodrich <[email protected]> > wrote: > >> > >> Mathis, > >> > >> The specification of the Restrict-by-Role tag can be found here: > >> HTML-249 > >> > >> I haven't totally specified out what this tag will do (I'm mentoring > >> the GSoC project this falls under), but I think it might not be > >> enough to handle Jonathan's use case. The idea of the tag is that > >> once you open a form, you can hide certain *parts* of a form from users > with certain roles. > >> Permissions for viewing/editing/deleting/adding an entire form would > >> happen at a higher level. > >> > >> Mark > >> > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of Mathias > >> Lin | Meta Healthcare > >> Sent: Thursday, April 12, 2012 10:41 AM > >> To: [email protected] > >> Subject: Re: [OPENMRS-DEV] Fwd: Regarding ticket TRUNK-1640: Add > >> roles-based form display feature > >> > >> Hi Ben, hi Mark, > >> > >> for TRUNK-1640, are you referring to the module that Mark mentioned, > >> > >> https://wiki.openmrs.org/display/projects/Filtering+Forms+on+Dashboar > >> d+%28Design+Page%29 > >> ? > >> > >> Actually I also see a GoC project for ticket HTML-285 in the list, > >> which is > >> https://wiki.openmrs.org/display/projects/HTML+Form+Entry+Module+Enha > >> ncements and the "Restrict-By-Role Tag" ticket mentioned there. > >> > >> I assume, both projects will be handled in GoC, and the estimated > >> time frame would be around end of August to be available. > >> > >> > I assume that Mathis is planning on building this functionality to > >> > meet Jonathan's requirements for his implementation. > >> > >> Yes, that was my idea. I will visit Jonathan in Manila in two weeks > >> to check his detailed requirements on-site. Actually both approaches > >> would work for this use-case, as currently only html forms are in use > >> there. I suppose the 'quick fix' would be to modify and adjust the > >> Jembi module to the current OpenMRS version. On the other hand, the > >> one GoC project looks pretty similar to what the Jembi module is doing. > >> > >> - Mathias > >> > >> > >> On Thu, Apr 12, 2012 at 9:43 PM, Mark Goodrich <[email protected]> > wrote: > >> > Our general feeling has been that we don't want to spend the time > >> > fixing the HTML Form Entry use case (HTML-285) but instead focus on > >> > the general use case (TRUNK-1640) with the intent that it should > >> > solve the needs of the user that that reported HTML-285. I was > >> > keeping > >> > HTML-285 open with the intention of closing it once TRUNK-1640 was > >> > implemented and we confirmed that it supported Jonathan Gallingan's > >> > use case. Perhaps it would be better if I marked HTML-285 as > >> > "won't fix" at this point to avoid confusion? > >> > > >> > > >> > > >> > @Ben-are you referring to the "Filtering Forms on Dashboard" project? > >> > > >> > > >> > > >> > I assume that Mathis is planning on building this functionality to > >> > meet Jonathan's requirements for his implementation. If TRUNK-1640 > >> > is indeed a GSoC project, there will have to be some co-ordination. > >> > I don't know if end of summer would meet Jonathan's timeframe. > >> > > >> > > >> > > >> > Mark > >> > > >> > > >> > > >> > From: [email protected] [mailto:[email protected]] On Behalf Of Ben > >> > Wolfe > >> > Sent: Thursday, April 12, 2012 9:00 AM > >> > To: [email protected] > >> > Subject: Re: [OPENMRS-DEV] Fwd: Regarding ticket TRUNK-1640: Add > >> > roles-based form display feature > >> > > >> > > >> > > >> > https://tickets.openmrs.org/browse/TRUNK-1640 is actually listed a > >> > summer of code project > >> > https://wiki.openmrs.org/display/RES/Summer+Of+Code+2012 . > >> > That is a bigger api-based change that will work for all form-based > >> > entry methods (formentry, htmlformentry, and xforms) > >> > > >> > The https://tickets.openmrs.org/browse/HTML-285 is just modify some > >> > work in htmlformentry done by Jembi to work with newer versions of > >> > openmrs. It will only work with htmlformentry. > >> > > >> > I'm not sure what the PHR module uses. I think it uses its own > >> > authentication mechanism to verify the patient is looking at their > >> > own page and/or it is a clinician looking at its own patient and > >> > grants proxy privileges. This isn't the same issue. (and we're > >> > trying to limit the use of proxy privileges going forward in favor > >> > of something yet-to-be-determined that is more secure and > >> > sustainable) https://wiki.openmrs.org/display/docs/PHR+Module > >> > > >> > Ben > >> > > >> > On Wed, Apr 11, 2012 at 3:18 PM, Joaquín Blaya > >> > <[email protected]> wrote: > >> > > >> > Hi Mathias, > >> > > >> > Though I can't help you with the ticket itself, I would ask that > >> > this also work for XForms if possible i.e. it doesn't display, or > >> > doesn't let you edit depending on roles. Though I don't know much > >> > about how the mechanism works, I think since both HTML and XForms > >> > are called from the same page when you click on the icon, it might > >> > not need any additional work. > >> > > >> > > >> > > >> > I've also added this to the ticket. > >> > > >> > > >> > Joaquín > >> > ___________________________________________________________________ > >> > Gerente de Desarrollo, eHealth Systems Research Fellow, Escuela de > >> > Medicina de Harvard Moderador, GHDOnline.org > >> > > >> > > >> > > >> > On Wed, Apr 11, 2012 at 2:17 PM, Mathias Lin | Meta Healthcare > >> > <[email protected]> wrote: > >> > > >> > (Not sure if my previous mail got through to the mailing list - I > >> > see it in my sent folder and list archive, but haven't received it > >> > in my inbox nor spam folder myself. Therefore again..) > >> > > >> > > >> > This mail concerns ticket "TRUNK-1640: Add roles-based form display > >> > feature", which is related to > >> > https://tickets.openmrs.org/browse/HTML-285 > >> > and therefore my question below probably addresses Ben & Darius > >> > directly: > >> > > >> > As I understand, the feature is almost done/issue resolved but some > >> > minor feedback is yet unfinished, and the ticket is unassigned at > >> > the moment (due to time constraints of the initial author). > >> > > >> > I will meet with Jonathan (the initial creator of ticket HTML-285) > >> > to discuss his requirements in detail as he needs his for his > >> > system implementation. As I understand, the ticket 1640 would > >> > resolve his issue actually, so I am looking into picking up this > >> > 1640 ticket, however, I would need some clarification the status, > >> > how to best implement/finish it, and eventually one of the core > >> > team members that I can turn to in case of any questions along the > >> > way, since this issue concerns the core, not an external module. > >> > Also, a rough estimation about the complexity of the task would be > helpful. > >> > > >> > Another question that is related is: I am aware of the PHR module > >> > at https://wiki.openmrs.org/display/docs/PHR+Module, which also > >> > deals with authentication and authorization in certain ways. I > >> > wonder how/if these modules implement two entirely different > >> > mechanisms, or if they're in some way related (though a bit > >> > different, one is role-centric, the other is user-centric; plus > >> > HTML-1640 is directly built into the core). -> or do we have two > >> > developments here in parallel that could actually solve the same > issue. > >> > > >> > - Mathias > >> > IRC: mathiaslin > >> > Skype: mathias.lin > >> > > >> > _________________________________________ > >> > > >> > To unsubscribe from OpenMRS Developers' mailing list, send an > >> > e-mail to [email protected] with "SIGNOFF > >> > openmrs-devel-l" in the body (not the subject) of your e-mail. > >> > > >> > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > >> > > >> > > >> > >> _________________________________________ > >> > >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail > >> to [email protected] with "SIGNOFF openmrs-devel-l" in the > >> body (not the subject) of your e-mail. > >> > >> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > >> > >> _________________________________________ > >> > >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail > >> to [email protected] with "SIGNOFF openmrs-devel-l" in the > >> body (not the subject) of your e-mail. > >> > >> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > > > > > > ________________________________ > > Click here to unsubscribe from OpenMRS Developers' mailing list > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
