Hello @mogoodrich , in the cases where its only used HFE, and not HFE-UI, on the encounterDate how they set the start and stop date for that widget? (I tought that would only be possible on the HFE-UI module) Thank you. CC: @mksd @dkayiwa
The key point here is that existing implementations should be able to update to the latest version of HFE within having to make any changes to their forms. The original idea was that we could do this via a global property, and if that global property isn’t set to true, everything would work the way is always did. If that solution is looking unfeasible, we will likely need to step back and rethink the design.
Take care! Mark
@jfigueiredo can you point on GitHub to the HFE UI-specific code that takes care of the encounter date’s datepicker boundaries?
We are making some new changes so that would be possible that if the Global Property is false, it will work without any other changes on the form.
The encounter date boundaries are set here:
And are executed on this JS file: openmrs-module-htmlformentryui/htmlForm.js at master · openmrs/openmrs-module-htmlformentryui · GitHub
@mogoodrich so HFE UI is responsible for setting the boundaries of the encounter datetime picker. The question is: where/how is this done when HFE only is used (without the UIFR)?
@jfigueiredo @dkayiwa @mksd … sorry, my original comment was more generic, because I saw the talk on the PR about now having HFE require HFE-UI, which we don’t want. I must have misread/misintrepreted the original question.
Yes, the encounter datepicker boundary-based-on-visit functionality was something that was added in around the time of the reference app and (I believe) is only available in HFE-UI.
So it’s certainly fine to maintain the dependency that if you need that functionality, you need to use HFE-UI. But there are many users that don’t use that.
I was more commenting on this: “I understand what you are saying, but that (at least for now) is not what is done. For use zonedDateTimeWidget we need HFE+HFE-UI, because HFE-UI is the module that send the client timezone to server.”
… which would be problematic if zonedDateTimeWidget is used any time showTime=true
Hope that helps! Mark
I must admit that I really don’t know the legacy HFE screens, but what happens with its datetime picker (if any) then?
It’s not limited to a date range, though people may have added their own custom JS to their forms to limit it.
Thanks @mogoodrich.
So @jfigueiredo, looks like we can have tz support with HFE only, it’s just that no particular care is given to the datepicker boundaries. Does that make sense?
Yeah, sorry if I wasn’t looking in the details of what the actual issue was, I just saw the statement “HFE will now require HFE-UI” and that set off red flags… 
That would be a possibility, but then we cannot send the hidden field in the form with the client timezone, we will only rely on the the UP property( set when the user choose the location), but yes, i think that could be done.
That’s fine IMO.