Summary. A combination of behaviors leads to very poor usability:
- A required date field with an optional end date starts out with "Show End Date" checked.
- The end date is validated if "Show End Date" is checked, even if the end date is blank and optional.
- A blank end date is not considered to be "after" the start date, causing a validation error
To reproduce, create a data field (I used the calendar popup widget; not sure if that's relevant). Make the field required. Have an end date, but don't make it required. Create a new node containing this field. Note that Show End Date is pre-checked. Enter a start date (only). Click OK. Get irritating validation error. Uncheck Show End Date. Form validates now.
That's bad enough, but now edit the same (perfectly valid) node. Show End Date is checked. Can't save the node, even though you didn't touch the date. Face palm.
Solutions: Either a blank end date should be considered a valid optional end date, even if Show End Date is checked or Show End Date should not be pre-checked just because the start field is required. I prefer the later.
I haven't studied Date enough to know where the end date's required status is stored (versus the entire field's). I *think* a test of the end date's required status is intended in date_element.inc, date_combo_element_process:
$show_todate = !empty($form_state['values']['show_todate']) || !empty($element['#default_value'][$to_field]) || $instance['required'];
What seems to actually be being tested is the whole field's required state, rather than the end date's.
Related to:
Comments
Comment #1
Ives commentedThis issue is also present in 7.x-2.x-dev. I fixed it, as you suggested, by removing $instance['required'] and adding a check for the required status of todate.
Comment #2
karens commentedThere were multiple reports of this and I fixed it on another report. Get the latest dev code and try again.