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]
