Bug #4604

Accession number does not reset for new calendar year

Added by Justin Simpson over 6 years ago. Updated about 6 years ago.

Status:VerifiedStart date:02/01/2013
Priority:MediumDue date:
Assignee:José Raddaoui Marín% Done:

100%

Category:AccessionsEstimated time:4.00 hours
Target version:Release 1.3.1
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

If the accession mask is set to "%Y-#iii", when the calendar year changes the %Y component changes in new accession numbers, but the counter does not reset to 1

Example
Current behavior
Accession #

2012-201
2012-202 last record created in 2012
2013-203 first record created in 2013

Expected behavior
Accession #

2012-201
2012-202 last record created in 2012
2013-1 first record created in 2013

If you manually reset the accession counter (Admin>Settings>Global>Accession Counter), it does not permit you to set the value to "0", so that the next record created will have accession number %Y-1; if you try to set the counter to "0", it reverts to the previous value of the counter when the changes are saved.

History

#1 Updated by Justin Simpson over 6 years ago

  • Project changed from CVA Archivematica to CVA AtoM Annual Maintenance Plan

#2 Updated by David Juhasz over 6 years ago

  • Project changed from CVA AtoM Annual Maintenance Plan to Access to Memory (AtoM)
  • Category set to Accessions
  • Assignee changed from Joseph Perry to José Raddaoui Marín
  • Target version set to Release 1.4.0

Move to AtoM bug tracker and assign to Radda.

#3 Updated by Jesús García Crespo over 6 years ago

  • Subject changed from accession number does not reset for new calendar year to Accession number does not reset for new calendar year

#4 Updated by Jesús García Crespo over 6 years ago

  • Estimated time set to 4.00

#5 Updated by Jesús García Crespo over 6 years ago

I'm not sure how to solve this. Glenn, do you have any suggestion? Do you think that if we allow to manually reset the counter is good enough?

#6 Updated by Glenn Dingwall over 6 years ago

I think that is sufficient. I've been able to reset the counter to other values, just not to '0', so that the next number issued is '1'

#7 Updated by José Raddaoui Marín over 6 years ago

  • Status changed from New to QA/Review
  • % Done changed from 0 to 100

Applied in changeset atom|commit:04866b466f9dc333a9e17c14968e32c99ddd1a04.

#8 Updated by Jessica Bushey about 6 years ago

  • Status changed from QA/Review to Verified

I tested resetting the Accession counter to "0" and it worked.
I also tested creating two Accessions with the same number (just in case this happened due to the ability of resetting the Accession counter to "0") and I received an internal 500 error from AtoM. I think this is a fine response. Not sure how easy it would be for the system to say "There is already an Accession with that number."

#9 Updated by Jesús García Crespo about 6 years ago

  • Target version changed from Release 1.4.0 to Release 1.3.1

Also available in: Atom PDF