Acquisition date in accession record behaving oddly
|Target version:||Release 2.3.1|
|Google Code Legacy ID:||Tested version:||2.4|
An issue was reported where the display value for accession date on the Accessions and Deaccessions screens was displaying incorrectly when the month was a two digit month, and the day was a single digit day.
E.g. 2016-12-06 would display as 2016-126
This change corrects this behaviour and adds unit tests for this date display function to validate future modifications.
#5 Updated by Dan Gillean over 5 years ago
- Status changed from QA/Review to Feedback
- Assignee changed from Dan Gillean to Nick Wilkinson
I can no longer recreate the issue so it seems resolved, but I noticed a small inconsistency in the UI interaction that might lead to confusion.
If you enter a date with leading zeros into a creation date field, e.g. 2001-01-01 - 2012-02-03, it will be copied to the start and end date fields as 2001-1-1 and 2012-2-3. On save, the zeroes are added, and are present if the user re-enters edit mode - so there are no errors, and the issue is avoided. However, the fact that you enter the zeroes and they are stripped in the corresponding fields before saving (THEN added back in during the save operation) seems confusing for end users as to correct practice, and unnecessary.
The same is true of the acquisition date field. Entering 2001-1-1 will save properly, and after save be rendered as 2001-01-01 - so there's no issue really at present - but our own JS confuses the issue in other date widgets.
Not sure if we can address this now, but adding this note for future reference - we should change the JS used in the date widget to stop stripping out leading zeroes (esp. if these are just added back in during save).
Will mark this as feedback for now, but it's also fine to verify depending on what we decide we have time for ATM.
#6 Updated by Dan Gillean over 5 years ago
- Status changed from Feedback to Verified
- Assignee deleted (
- Target version changed from Release 2.4.0 to Release 2.3.2
Will file a separate issue for the date helper widget issue, as it is related but separate from this, and the actual issue in question here has been resolved.