EBMS Tickets

I'm assigning this to Alan because there's a significant overlap with OCEEBMS-5, on which he's done a considerable amount of work.

[The title of this ticket seems a little bit mismatched, as it implies that the issue has to do with date display, whereas it's clear from the original description of the request that it has to do with the widgets used for entering the dates.]

I changed the title of the ticket to match the nature of the issue.

First step is to determine the scope of the issue. Here's my attempt at enumerating the date fields we have and their UI, of which I have found several types.

Separate dropdown picklists for month/day/year

This is the UI specified in the original visual design, as illustrated in the attachment [separate-date-component-fields.png|^separate-date-component-fields.png]. This interface uses the built-in Drupal date field type. Sometimes ranges of dates were specified with the end-point hidden until called up dynamically with a RANGE checkbox (see attachment [range-separate-date-component-fields.png|^range-separate-date-component-fields.png]). There is one pair of fields for month and year which is similar from the user perspective, though implemented without using the built-in Drupal date field type (see attachment [year-month-fields.png|^year-month-fields.png]). Here are the places where I found this type of date interface:

• Citations Not Selected for Full Text Retrieval report form

• Citation Summary Topic Changes report form

• Imports report form

• Documents report form

• Literature Review report form

• Citations By Status (On Agenda) report form

• Citations By Status (Editorial Board Decision) report form

• Search request form (multiple fields, including the one Month/Year pair)

Date text fields

Some pages were implemented for requirements which had no accompanying visual design, and for at least one of those pages, free-form text fields were used for dates, with the validation of the values in custom code. The only page for which I found such fields was the [Print Packets form|^free-text-date.fields.png].

Date popup fields from the Calendar module

At some point in the project the schedule was collapsed, requiring the augmenting of the development team, a decision to make heavier use of third-party modules, and a decision to avoid the extra work to customize the user interface provided by these modules to match the original visual design requirements (as embedded in Ashleigh's mockups). As a result, date fields with popup calendar widgets were introduced. Although they didn't match the original visual design requirements, the users liked the convenience of the popups and asked that they be used for other pages as well. The fields from the Calendar module are illustrated in the attachments [date-popup.png|^date-popup.png] and [date-popup-start-end.png|^date-popup-start-end.png]. The pages I found using these fields are:

• Event creation and editing form

• Travel report forms

• Responses By Reviewer report form

• Articles Without Responses report form

• Manager Packets page

• Manager Reviewed Packets page

Date popup fields from the Webforms module

The module used to implement the Hotel Request and Reimbursement Requests forms came with a date popup field which included a calendar icon to bring up the date selection widget, which functions pretty much the same way the one from the Calendar module does, though it looks a bit different, as illustrated in the attachment [hotel-request-date-field.png|^hotel-request-date-field.png].

Have I left out any date fields used in the EBMS? I searched the source code for date fields using a technique which made assumptions about how Drupal date fields would be coded, and that may not have found everything (it certainly didn't find the fields used on the Print Packets form, which don't use Drupal date fields at all).

After we are confident that we've identified all the form fields used for dates in the system, the next steps will be:

✔ determine the technical feasibility of changing fields from one type to another;
✔ decide which field UI is preferred;
✔ decide which fields to change; and
✔ implement the changes

I have done some preliminary investigation, proceeding on the assumption that any date fields you identify that I have missed will match one of the four categories I cataloged above. So while it's important that you find any date fields I missed, it doesn't seem as if we need to delay before going on with the analysis.

What I found was:

1. It's not feasible, without risky (by which I mean fragile, subject to easy breakage when third-party modules are upgraded) and complicated code to change the field behavior, or taking over a fork of one or more of the third-party modules and owning their maintenance ourselves, to make the date popups from the Calendar module and those from the Webforms module look and behave like each other. So making a date field on the travel request forms (built using the Webforms module) match the popup fields used elsewhere on the site is not a reasonable option. The only safe way to do that would be to completely re-implement the travel request forms from the ground up without using the Webforms module, which would be a very expensive undertaking, certainly not falling in the time frame allocated for this release, even taking into account how well ahead of schedule we are. And I haven't found a way to make the core Date/Calendar module's date fields use the three dropdown picklists for the date value components (the way the Webforms module does it). I don't find the Webform date UI as clean and attractive, with all its separate sub-widgets, as the interface used by the Calendar module anyway, and I suspect none of us would have preferred to make all the date fields in the system look like they do on the travel request forms.

2. It is possible to make the date fields in the first two categories described in my previous comment match the ones which use the Calendar module's popup.

3. I have confirmed that it is possible with the Calendar module's popup date field to configure the field to allow you to type in partial dates (e.g., "2014" or "2014-06") and have searches and filters automatically search for an entire year or month this way, without having to specify the starting and ending dates in full, as Robin hoped to be able to do. In fact, I would be able to enhance that ability so you could type "2012" in the start field and "2014" in the ending field, and have the query look for matches betweeen 2012-01-01 and 2014-12-31.

4. I can make the Calendar popup date fields use some of the more appealing aspects of the Webform UI. I am able, for example, to replace the Month and Year dropdown lists with the more attractive display of the current month and year, as is done by the Webform module, and I can include a little calendar icon as part of the date input field as a visual cue that a popup is available, the way the Webform module does (though I would model this after the way it is done in the MyNCI site, with the icon tucked inside the right end of the date entry box, instead of having it outside the box).

So here's what I recommend:

1. Leave the date fields on the travel request forms as they are (they're the only forms used by the board members which involve date fields, and the only forms created using the Webform module).

2. Have the rest of the date fields on the site use the Calendar module's popup date field, modified to incorporate the best features of the Webform popup.

3. Use side-by-side date fields, separated by a dash, for date ranges consistently (currently some ranges use side-by-side fields, some stack the two fields vertically, and some of those hide the second field until a "Range" checkbox is clicked).

4. Enhance the date range logic so that partial dates can be entered in any date field, causing the filtering logic to handle the date as a range.

I have posted [existing|^citations-not-selected-existing-ui.jpg] and [proposed|^citations-not-selected-date-range-with-popups.jpg] screen shots to this ticket as illustrations of what I'm describing. I'm hoping for timely feedback on my proposal, in the interest of keeping to the schedule.

There are other inconsistencies in form layout, which I suggest we defer addressing for another release, if at all. Not all forms have the field labels aligned to the right of the fields, for example. I regard these broader inconsistencies as out of scope for this issue.

Here's a [screen shot|^mynci-date-fields.jpg] showing the date fields on the MyNCI site, which I am emulating in my proposed approach to the use of the calendar icon for this issue.

Robin and I have read and discussed this issue and agree with your recommendations with one exception. On the Search Database page, the Publication Date currently has month and year data fields. We'd like to keep this as is because we would never search for a publication by day.

I also wanted to mention that Bonnie did look through the site to see if there were any additional date fields that you didn't find in your search, and (not surprisingly), she didn't find any.

P.S. - Thanks for all of the visuals. They helped!

OK, thanks for the quick turnaround!

Ready for review on DEV. Massive changes for this one, so lots of testing, please.

Date modified on the following pages:

✔ Citations Not Selected for Full Text Retrieval report form
✔ Citation Summary Topic Changes report form
✔ Imports report form
✔ Documents report form
✔ Literature Review report form
✔ Citations By Status (On Agenda) report form
✔ Citations By Status (Editorial Board Decision) report form
✔ Search request form (multiple fields, including the one Month/Year pair)
✔ Packet printing request form
✔ Event creation and editing form
✔ Travel report forms
✔ Responses By Reviewer report form
✔ Articles Without Responses report form
✔ Manager Packets page
✔ Manager Reviewed Packets page

I'm having some problems with dates. So far:

1. I received a message "Invalid Date Range" for the Literature Reviews Report, using various date combinations.

2. The dates on several pages are being converted into nonsensical dates (same as reported on the reviewed packets page in a separate issue). So far, I've also seen this on the following pages:

• citations by status (on agenda) report

• citations by status (ed board decision) report

• responses by reviewer report

• articles without responses report

• import report

• documents report

I think it would be worth checking the code for each of the date fields above (referring to the list in the previous comment), unless there's a global fix.

Related (I assume): The Reimbursement Request Report does not find any matches when I submit a date range.

Actually, I started out by trying to "fix" code in a bunch of places, and ended up making things worse. Then I discovered that Drupal's cache had gone haywire again on DEV. I cleared the cache, backed out all the misguided "fixes" and now things are at least better (I don't dare say "perfect"). :-)

So far, things are looking pretty good. I've verified the following date fields (more to come):

Citations Not Selected for Full Text Retrieval report form
Citation Summary Topic Changes report form
Imports report form
Documents report form
Literature Review report form
Citations By Status (On Agenda) report form
Citations By Status (Editorial Board Decision) report form

I ran into an error when checking the "date tag added" date fields on the search page. I ran the search, which came up fine, but when I clicked "Refine Search" I received the following error message:

Notice: Trying to get property of non-object in EbmsSearchSpec->__construct() (line 465 of /local/content/web/appdev/sites/ebms.nci.nih.gov/modules/custom/ebms/search.inc).

All other fields seem to be working properly. Thank you!

For clarification when QA testing, the "Manager Packets" page is the "View/Edit Packets" page.

Notice: Trying to get property of non-object ...

Fixed the typo that caused that message.

I've verified this latest fix and I've checked each of the date fields listed below, so I'm considering this verified on DEV.

Verified on QA.

Verified on prod.