Bug #4604
Accession number does not reset for new calendar year
| Status: | Verified | Start date: | 02/01/2013 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | ||
| Assignee: | José Raddaoui Marín | % Done: | 100% | |
| Category: | Accessions | Estimated 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 7 years ago
- Project changed from CVA Archivematica to CVA AtoM Annual Maintenance Plan
#2 Updated by David Juhasz over 7 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 7 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 7 years ago
- Estimated time set to 4.00
#5 Updated by Jesús García Crespo over 7 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 7 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 7 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 over 7 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 7 years ago
- Target version changed from Release 1.4.0 to Release 1.3.1