...
See Jira Legacy server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-4137 Jira Legacy server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-4136
Use Cases
Case 1
- Identifier must (or should) be globally unique - requires validation against all tenants
- All tenants share "ownership" of this identifier
- Requires error handling and/or manual tenant assignment in the event of duplicates
Case 2
- Identifier must be accessible and usable by all tenants, but with localization allowed
- All tenants use this identifier, but this identifier can be tailored per tenant
- Uniqueness can be achieved via prefix. suffix or other internal handling
Case 3
- Identifier must be visible to all or specific tenants, but editable only by the owning tenant
- Uniqueness can be achieved via prefix, suffix or other internal handling
Case 4
- Does not need to be unique
- Disambiguation options
| Rec Type | ID | Editable? | Global/Local | Why unique? | Explicit or augmented? | System-generated or manual? | Responsible Team | JIRA Link | Use Case | Notes | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Tenant | Name | Y | G | E | M | Thunderjet | Done | ||||||||||||||||
| Tenant | Code | ? | G | E | M | Thunderjet |
| Tenant Code is intended as a prefix to enforce identifier uniqueness across multiple tenants (e.g. prepending to an acquisition unit to ensure uniqueness across the consortium) | |||||||||||||||
| Item | Barcode | Y | G | Resource sharing | Augmented | M | Folijet Spitfire | Nearly impossible to eliminate barcode duplication across a large consortium, but need to differentiate ownership. | |||||||||||||||
| Item | Item | N | Folijet Spitfire | Even if not unique, do we need some sort of indicator of which tenant the Item HRID belongs to? | |||||||||||||||||||
| Instance | Instance HRID | N | Folijet Spitfire | Even if not unique, do we need some sort of indicator of which tenant the Instance HRID belongs to? | |||||||||||||||||||
| Holdings | Holdings HRID | N | Folijet Spitfire | Even if not unique, do we need some sort of indicator of which tenant the Holdings HRID belongs to? | |||||||||||||||||||
| Organization | Code | L | Thunderjet |
| 2 | ||||||||||||||||||
| Organization | Name | L | Thunderjet |
| 2 | ||||||||||||||||||
| Orders | PO Number | Thunderjet |
| 3 | |||||||||||||||||||
| Orders | PO Line | Thunderjet | 3 | I can't identify any scenarios where Tenant A would need to see a unique POL for Tenant B | |||||||||||||||||||
| Invoices | Invoice # | L | Thunderjet | 3 | |||||||||||||||||||
| Acquisition Unit | Name | G | Shared order across multiple tenants | Augmented | M | Thunderjet |
| 1 | Possible use case: central tenant acquires on behalf of other tenants. | ||||||||||||||
| Fiscal Year | Name | L | Thunderjet | 3 | |||||||||||||||||||
| Fiscal Year | Code | L | Thunderjet | 3 | Presumptive. Need confirmation from consortia. | ||||||||||||||||||
| Ledger | Code | L | Thunderjet | 3 | |||||||||||||||||||
| Group | Code | L | Thunderjet | 3 | |||||||||||||||||||
| Fund | Code | L | Thunderjet | 3 | |||||||||||||||||||
| Voucher | Number | L | Thunderjet | 3 | |||||||||||||||||||
| User | Username | Y | G | Users can have multiple affiliations; need to avoid conflict. | Explicit | M | Thunderjet |
| 1 | Use case: Central office has a John Doe with limited permissions across multiple tenants. One of those tenants has a staff member Jane Doe. Folio cannot support 2 "jdoe" logins within the same instance. | |||||||||||||
| User | Barcode | Y | G | M | |||||||||||||||||||
| Service point | For additional info please refer to
| ||||||||||||||||||||||
| User | External system ID | The external system ID for the User. The field is auto-populated if it is included in source data provided by an external system. | Auto-populated data in source data provided by external system |
|
Processes Potentially Affected
General
- Staff/user management
- If another record type's number is stored in a given app or record, how does that affect the storing app/record if the owning app/record changes the number or number structure, e.g.
- Inventory Instance doesn't know which SRS MARC ID it's related to, but SRS MARC record knows which Instance UUID it's related to
- Inventory Instance links to the SRS MARC and allows for quickMARC lookup/edit/update SRS MARC/update Instance, based on that relationship
- Inventory Instance/Holdings/Items do not know which POL(s) they are related to, but each POL knows every Instance/Holdings/Item related to it
- Inventory displays POL info in the Instance/Holdings/Item
- Inventory Instance doesn't know which SRS MARC ID it's related to, but SRS MARC record knows which Instance UUID it's related to
Circulation
- CI/CO
- Requests
- Loans
- Fines/Fees
- Users
...
| Question | Status | Conclusions | Comments | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Are any record types or unique identifiers missing in the above list, which will need to be visible or partially visible to some or all consortia members? |
| ||||||||||
| Are there any circumstances under which other order-specific information should be shared with the consortium? |
| ||||||||||
| Do IDs need to be natively unique or can they be augmented into uniqueness? | |||||||||||
| Why do we need uniqueness on a per record basis? | |||||||||||
| When is it OK to duplicate an ID? | |||||||||||
| Cross-consortia/multi-consortia uniqueness? (Consortium-to-consortium) |