EBMS Tickets

Developer note: there are multiple calendar widgets; need to make sure we are using the desired widget.

Looking at https://ebms-dev.nci.nih.gov/travel/reimbursement-request, I see that "ARRIVAL DATE" and "DEPARTURE DATE" both have calendar widgets next to the Month / Day / Year fields. "TRANSPORTATION DATE" and "PARKING AND TOLLS DATE" both have the same Month / Day / Year fields but have no calendar widgets.

I presume that the purpose of this task is to make the latter two be just like the former two, each with the same calendar widget used in the two fields that have calendar widgets. That's what I'll assume until someone says I'm mistaken.

That's right, Alan. Thanks.

I've gone over the existing logic with Bob and we also got some good
ideas from Dan and I think we have a plan about what to do.

It would seem straightforward - just replace the month/day/year date
input fields with a calendar popup widget.  Easy, right?  Well, maybe
not.  The problem is that the month/day/year input fields and the
calendar widget produce dates in very different formats.

What I'm planning to do is to, experimentally at least, is the
following:

    Replace the month/day/year input field with a calendar popup widget.

    Process the data when it is submitted to change the input data from
    the format produced by the popup widget back to the original format.

    Store the new data in the database using that original format.

Assuming I can do that straightforwardly, I'm thinking that all of the
existing reports on this data will continue to work without
modification.  I'm also thinking that we never edit this data, so I
never have to do a reverse conversion to recreate the calendar widget
format and put the data back on the screen for editing.

The format produced by the calendar widget is probably a better format
for straightforward programming, but we've already written code to use
the old format and we'd have to re-write existing reports either to use
two different date formats, or else to use the new format exclusively
and run a conversion on the existing data.  That's the cleanest solution
but is relatively much more expensive and had no specific benefit for
users, only for future program modifications.

I'm going to make the changes on a private virtual machine and make sure
the reports work and the database is okay.  If all goes well, I'll
install the changes on DEV.  If I learn that the plan has unforeseen
problems, I'll report back.

In case you are wondering about why you got two identical appearing comments from me, the second one fixes a one character typo. It probably wasn't worth it, but extra credit goes to anyone who spots the typo without using a diff program.

I think I've got this one licked. Please test thoroughly.

• R12230 modules/custom/ebms_webforms/ebms_webforms.module

Promoted to QA.

Verified on QA.

Verified on production.