Bug #10716

Acquisition date in accession record behaving oddly

Added by Steve Breker over 5 years ago. Updated over 5 years ago.

Status:VerifiedStart date:12/06/2016
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Accessions
Target version:Release 2.3.1
Google Code Legacy ID: Tested version:2.4
Sponsored:No Requires documentation:

Description

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.


Related issues

Related to Access to Memory (AtoM) - Bug #10726: Date autocomplete helper strips leading zeroes from dates New 01/03/2017

History

#2 Updated by Steve Breker over 5 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from Steve Breker to Nick Wilkinson

Copied from 10641.

PR completed - noted on 10641.

https://github.com/artefactual/atom/pull/487

Ready for QA.

#3 Updated by Dan Gillean over 5 years ago

  • Category set to Accessions
  • Target version set to Release 2.4.0

#4 Updated by Nick Wilkinson over 5 years ago

  • Assignee changed from Nick Wilkinson to Dan Gillean

#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 (Nick Wilkinson)
  • 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.

#7 Updated by Dan Gillean over 5 years ago

  • Related to Bug #10726: Date autocomplete helper strips leading zeroes from dates added

#8 Updated by Dan Gillean over 5 years ago

  • Target version changed from Release 2.3.2 to Release 2.3.1

Also available in: Atom PDF