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

[UXPROD-4137] Managing unique identifiers in acquisitions records Created: 17/Mar/23  Updated: 30/Nov/23  Resolved: 22/Nov/23

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

Type: New Feature Priority: P2
Reporter: Dennis Bridges Assignee: Joseph Reimers
Resolution: Won't Do Votes: 0
Labels: ecs, unique-identifiers
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UXPROD-4207 Globally unique identifiers in consor... Closed
is defined by UXPROD-4208 Globally visible unique identifiers i... Closed
is defined by UXPROD-4270 Vendor data (address, etc.) should be... Draft
Relates
relates to UXPROD-4157 Display Acquisitions data on consorti... Draft
Release: Ramsons (R2 2024)
Epic Link: Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 2)
Front End Estimate: Large < 10 days
Front End Estimator: Khalilah Gambrell
Front-End Confidence factor: 30%
Back End Estimate: XXL < 30 days
Back End Estimator: Khalilah Gambrell
Back-End Confidence factor: 30%
Development Team: Thunderjet
PO Rank: 0

 Description   

Current situation or problem: Acquisitions 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

Out of scope

LCAP-related requirements - existing functionality meets their criteria.

Use case(s)

  1. Identifier must be globally unique
    • User - Username Moved to UXPROD-4308 Closed
    • Acquisition Unit - Name
    • Note: Go-live requirement
  2. Identifier must be accessible and usable by all tenants but with tenant-specific localization
    • Organization - Name
    • Organization - Code
    • Note: LOW PRIORITY
  3. Identifier must be visible to all or specific tenants but only one tenant has write/delete ability.
    • Orders - PO Number
    • Orders - PO Line
    • Invoices - Invoice Number
    • Fiscal Year - Name
    • Fiscal Year - Code
    • Fund - Code
    • Group - Code
    • Ledger - Code
    • Note: Not required for go-live

Proposed solution/stories

Case 1:

  • Newly created identifiers should have uniqueness verified across all tenants
  • If an identifier turns out to be non-unique, provide a mechanism for users to associate that identifier with a specific tenant whenever that identifier is accessed (i.e. association per use, not forced permanent association.)

Case 2:

  • Allow (or force) the record associated with the identifier to be replicated across all tenants (e.g. basic Organization info such as address and phone number)
  • Allow other tenants to manage some or all information associated with the record for that specific tenant
    • e.g. Contact persons, Integrations
  • Allow a tenant to define a record associated with the identifier as non-shareable

Case 3:

  • Allow other tenants to view the identifier and information associated with that identifier
  • Allow tenants to define a record associated with a given identifier as non-shareable
    • e.g. suppress a specific Order or POL from consortium view
  • Allow tenants to define all records associated with a given identifier as non-shareable
    • e.g. designate all Funds as non-shareable

Links to additional info

Unique identifier analysis: https://folio-org.atlassian.net/wiki/x/KBNU

Questions



 Comments   
Comment by Joseph Reimers [ 21/Jul/23 ]

I'm disassociating this feature from the LCAP project because it was originally created for ECS and is distinct from LCAP's unique identifier requirements.

Comment by Joseph Reimers [ 22/Nov/23 ]

This was a parent analysis feature and we've done what we know we needed to do. If additional use cases emerge, we will create appropriate features specific to those use cases.

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