Feature #9917

Validate and enforce the uniqueness of accession identifiers

Added by Dan Gillean about 4 years ago. Updated almost 3 years ago.

Status:VerifiedStart date:05/20/2016
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:AccessionsEstimated time:10.00 hours
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:
Sponsored:Yes Requires documentation:

Description

This feature will build upon the work described in tickets #9897 and #9915, which will allow the accession number to be edited, and the accessions mask to be disabled by an administrator.

To ensure unique values are maintained even when a user manually edits the accession number or disables the mask and uses a number of their choosing, we will validate the data against accession IDs already in use, prior to saving. If a number is found not to be unique, the user will be given a notification, and any data entered into the edit page will be preserved, so the user can modify the accession number until an acceptable, unique value has been entered. This will involve:

  • Using JavaScript to verify the uniqueness of the accession number prior to posting the page data to the database
  • If the value is not unique, stay on the edit page so no other data is lost, and inform the user

accession-number.png (24.7 KB) Dan Gillean, 06/13/2016 08:08 PM


Related issues

Related to Access to Memory (AtoM) - Feature #9915: Include a setting to disable the accession mask Verified 05/25/2016
Related to Access to Memory (AtoM) - Feature #9897: Allow accession numbers to be edited by users via the use... Verified 05/24/2016

History

#3 Updated by Dan Gillean about 4 years ago

  • Related to Feature #9915: Include a setting to disable the accession mask added

#4 Updated by Dan Gillean about 4 years ago

  • Description updated (diff)

Update description to point to correct related public tickets.

#6 Updated by Dan Gillean about 4 years ago

  • Related to Feature #9897: Allow accession numbers to be edited by users via the user interface added

#7 Updated by Jesús García Crespo about 4 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Mike Cantelon to Dan Gillean

#8 Updated by Dan Gillean about 4 years ago

  • File accession-number.png added
  • Status changed from QA/Review to Feedback
  • Assignee changed from Dan Gillean to Mike Cantelon

Testing this on qa/2.4.x branch....

See attached image - was never given any warning about using the exact same accession number. In the UI, was able to create identical ones... however, I noticed that internally (at least, going by the slug), it actually bumped me ahead to the next available accession number... but I was never warned. Record saved immediately.

#9 Updated by Dan Gillean about 4 years ago

HMMMMMMM very weird. I tried to repeat this one more time, and THEN I saw the JS warning in action. I appreciated that the create button was disabled as well. so..... it works? But i'm still confused why i was able to create a duplicate the first time around.

First time I had the accession mask setting turned on, but still edited the value. Second time, I had it turned off. Going to test a bit more and see if that's it, tomorrow.

#10 Updated by Mike Cantelon about 4 years ago

Cool... maybe the JS that the validation code's in was cached initially (so the updated JS with the prevalidation didn't kick in)?

#11 Updated by Dan Gillean about 4 years ago

  • Status changed from Feedback to Verified

After further testing, I've been unable to recreate the initial problem reported. We've also received sign-off from the sponsoring institution. Considering this verified. Thanks Mike!

#12 Updated by Dan Gillean almost 3 years ago

  • Assignee deleted (Mike Cantelon)
  • Requires documentation deleted (Yes)

Also available in: Atom PDF