Feature #11162

Identifier enhancements

Added by Mike Gale about 3 years ago. Updated about 3 years ago.

Status:VerifiedStart date:04/25/2017
Priority:MediumDue date:
Assignee:Sara Allain% Done:

0%

Category:Information objectEstimated time:20.00 hours
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:
Sponsored:Yes Requires documentation:No

Description

This feature will give users a way of automatically generating identifier values, based on a mask similar to that used for generating accession numbers. Work involved on this enhancement includes:

  1. Add and identifier mask and counter to Admin > Settings
  2. In the Archival description edit page: add a button next to the identifier field to generate next unique identifier, based on mask. Make sure work is done on all templates
  3. Add a setting in Admin > Settings that will auto-populate the identifier field in new description edit pages when turned on, based on the mask values

Notes on the feature:

  • This will be implemented in a way very similar to the accession number mask and counter
  • The feature will work the same for all levels of description. Once generated, values will still be editable by the user.
  • AtoM will not perform any checks for uniqueness - if the same value is used (e.g. if the counter is changed, if users have manually edited generated codes or manually entered their own codes, etc), the record will save as expected, but without any indication of duplication, as AtoM does not require identifier values to be unique in the system.
  • If reference inheritance is used, then users will likely not want to add hardcoded elements to the mask value - instead, they could use the button to generate the next unique number at the top level, edit it to add a fonds-specific alphabetic string as a precursor, and rely on ref code inheritance for this to be present in lower levels. This will be outlined with examples in the related documentation.
  • When the setting is turned ON, the identifier field will be auto-populated with the next available unique value based on the mask (but still editable by the user). When the setting is turned OFF, the identifier field will be blank in new description edit pages, but the button to generate will still be present if the user wishes.
  • The mask will NOT automatically populate values for child records created in the "Add new child records" widget. You can manually enter a value there if desired, but leaving it blank will not cause an identifier to appear.

History

#2 Updated by Mike Gale about 3 years ago

  • Status changed from New to Code Review
  • Assignee changed from Mike Gale to José Raddaoui Marín

Hi Radda, do you think you can code review this for me? https://github.com/artefactual/atom/pull/561

If you are busy please feel free to re-assign to someone else like Mike C or Steve!

thanks

#3 Updated by José Raddaoui Marín about 3 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from José Raddaoui Marín to Mike Gale

#4 Updated by Mike Gale about 3 years ago

  • Status changed from Feedback to Code Review
  • Assignee changed from Mike Gale to José Raddaoui Marín

Hi Radda, I tried to address all your CR suggestions with one exception.

You'll notice I kept identifier_counter using QubitSetting rather than sfConfig. This is because I ran into a very bizarre bug where sfConfig::get() was pulling in an outdated counter variable. In my case, it got stuck on 10 (the value that was initially there when I swapped to sfConfig). If I created a new record, the counter would increment in the database but sfConfig was still returning 10. I could get around this by calling sfConfig::add(QubitSetting::getSettingsArray()); every time in QubitInformationObject but that feels way too hacky.

Also which I found very strange is identifier_mask setting didn't have this issue, even if I changed it (maybe the admin->settings save action does sfConfig::add(QubitSetting::getSettingsArray()); every time? not sure...). Do you know of any solution to this? I think if it's going to take more than several minutes we should just keep using QubitSetting.

thanks

#5 Updated by José Raddaoui Marín about 3 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from José Raddaoui Marín to Mike Gale

Hi Mike, looking great!

I think we save the settings added to sfConfig in cache. That's probably why it's not updating. If the accessions counter is using sfConfig to get the counter, it's probably clearing the settings cache at some point (like it's done in the settings forms when they are processed). I'd check if that's true and an easy fix, if not feel free to keep it as it is.

#6 Updated by Mike Gale about 3 years ago

  • Status changed from Feedback to In progress

#7 Updated by Dan Gillean about 3 years ago

  • Description updated (diff)
  • Category set to Information object
  • Sponsored changed from No to Yes
  • Requires documentation set to Yes

Update feature description

#8 Updated by Dan Gillean about 3 years ago

  • Target version set to Release 2.4.0

#9 Updated by Mike Gale about 3 years ago

  • Status changed from In progress to QA/Review
  • Assignee changed from Mike Gale to Sara Allain

#10 Updated by Sara Allain about 3 years ago

  • Status changed from QA/Review to Verified
  • Requires documentation changed from Yes to No

Looks good! I added documentation to User manual > Administer > Settings and updated the Global Settings screenshot on that page.

Also available in: Atom PDF