personalcancertoolkit / openmrs-module-patientportaltoolkit

Other
7 stars 9 forks source link

Support mm-dd-yyyy format for birthdate field #511

Closed bmamlin closed 1 year ago

bmamlin commented 1 year ago

Both the datepicker and the placeholder text for the birthdate field would ideally be in the format "mm-dd-yyyy" (the same as what RedCap uses) instead of the current yyyy-mm-dd (with mimatched placeholder text) that we have now.

PhilipAdeoye commented 1 year ago

When dates in the format of "mm-dd-yyyy" are pasted into the Birth Date field (in the style comfortable to the users), the datepicker plugin that acts on that Birth Date field gets "confused" and doesn't update its internal date to match the pasted-in date.

Solution: change the datepicker's format from "yyyy-mm-dd" to "mm-dd-yyyy". Now, the datepicker understands the pasted-in dates.

When the form is submitted, OpenMRS' API requires the date to be in the "yyyy-mm-dd" format. Any other format causes a 400 Bad Request error.

Solution: After the "mm-dd-yyyy" date is pasted in or chosen with the datepicker, reformat the date into the "yyyy-mm-dd" format. Date.toISOString() returns a string resembling "2023-04-19T18:41:09.330Z". Split off the first part before the T and 👍

PhilipAdeoye commented 1 year ago

Instead of reformatting the contents of the date input, store the reformatted date on a data- attribute like data-reformatted-date. And when submitting the form, instead of submitting the value from jq("#inputBD").val() (the content of the date input) use jq("#inputBD").data('reformattedDate') (the stored reformatted date)

This way, users see what they typed or pasted-in in the 'mm-dd-yyyy' format, but the submitted data is in the 'yyyy-mm-dd' format that the OpenMRS api will accept

PhilipAdeoye commented 1 year ago

This latest approach is problematic because the date that the user sees could end up being very different than the date that actually ends up getting submitted, and the user has no way to verify what's getting submitted