Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1) (UXPROD-4049)

[UXPROD-4135] Managing unique identifiers in Inventory records Created: 17/Mar/23  Updated: 19/Sep/23  Resolved: 01/Jun/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Poppy (R2 2023)
Parent: Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1)

Type: New Feature Priority: P2
Reporter: Dennis Bridges Assignee: Khalilah Gambrell
Resolution: Won't Do Votes: 0
Labels: LC1, cataloging, ecs, metadatamanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2023-05-31-07-46-25-143.png     PNG File image-2023-05-31-07-48-44-170.png     PNG File screenshot-1.png     PNG File screenshot-2.png    
Release: Poppy (R2 2023)
Epic Link: Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1)
Development Team: Spitfire
PO Rank: 0

 Description   

Current situation or problem: Inventory records contain a number of human readable IDs that are expected to be unique within a given library. Some of these identifiers may also need to be unique across consortia. FOLIO needs to identify what identifiers in the Instance, Holding and Item should be unique within a member vs what should be unique across members.

In scope

Apply the method for managing unique IDs across consortia members to the unique IDs enumerated below

  • Instance HRID
    • Can be handled by defining rules for uniqueness and Inventory settings for HRID prefixes in each tenant
  • Holdings HRID
    • Can be handled by defining rules for uniqueness and Inventory settings for HRID prefixes in each tenant
  • Item HRID
    • Can be handled by defining rules for uniqueness and Inventory settings for HRID prefixes in each tenant
  • Item barcode
    • Dennis Bridges  is there a need for this to be handled at the consortia level? Can this be handled locally and thus no change to current functionality? DB: Based on logic being implemented for reshape DCB FOLIO will not need to concern itself with consortial uniqueness of item barcode
  • Assume instance/holdings/item/authority UUIDs are already handled for uniqueness?
  • Location code to support > Holdings/Items permanent and temporary location fields (values are setup in Settings > Tenant > Location setup
    • Location code? (It seems logical to enforce the uniqueness of location codes by attaching a prefix from the consortia membership table.) Location code will be critical for matching during import. Potentially all codes in the consortia should be unique to help simplify the batch update process. 

 

Out of scope

Use case(s)

Proposed solution/stories

Links to additional info

Questions



 Comments   
Comment by Khalilah Gambrell [ 31/May/23 ]

Hey Dennis Bridges / Ann-Marie Breaux / Christine Schultz-Richert, I outlined all instance/holdings/item/authority unique identifiers that I know about. 

As far as location codes, unfortunately we have not enforced any validation to prevent duplicates. In fact, libraries can change these values at anytime. Is it possible for phase one to have a handshake agreement to not create duplicates?  I believe this is how it is handled today. 

 

Comment by Ann-Marie Breaux (Inactive) [ 31/May/23 ]

Hi Khalilah Gambrell I think the tricky part for this is that there may be many libraries within MOBIUS with location codes of ref or gen or stacks or main, but I don't know for sure. Seems like something that should be discussed and coordinated with the IC folks analyzing and migrating their existing data.

Then as long as the permissions to create/edit locations are locked down for the member libraries (and controlled by the MOBIUS consortial staff), there shouldn't be an issue with random new duplicative codes popping up.

Comment by Khalilah Gambrell [ 31/May/23 ]

Hey Ann-Marie Breaux - I agree. We should discuss with ICs to make sure that it is unique. Is a location code based on library code only or the Institution code + Campus code + Library code? 

Comment by Ann-Marie Breaux (Inactive) [ 31/May/23 ]

Khalilah Gambrell It's just based on the location code. It doesn't have to reference the Inst/Campus/Library codes. On Snapshot, they do, e.g. KU/CC/DI/M, but some libraries just assign plain codes for locations. See attached example from Orchid Bugfest.

Best bet is to talk to MOBIUS about it. I'm guessing they are using some guidelines, and/or could provide lists of the current location codes for the member libraries. I think the larger and more complex the library or group of libraries, the more they will try to follow clear conventions. Looking at Duke and Chicago in Orchid Bugfest bears that out.

Comment by Khalilah Gambrell [ 31/May/23 ]

Ahh. Got it. Thanks Ann-Marie Breaux 

Generated at Fri Feb 09 00:37:33 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.