* Should we include an (optional) cleanup script? Decided no.
* For existing Instances/SRS MARC Bibs that have the same UUID, is there significant risk if they are not cleaned up? While this should be corrected going forward, cleanup of existing ones feels risky. Will not change.
* If this was happening in Juniper, do we need a Juniper HF? No
* Are different UUIDs being assigned to Instance and SRS MARC Bib, but not being documented properly in the 999, or are duplicate UUIDs being assigned? Separate story for documentation update
- Does this also affect Inventory Holdings and SRS MARC Holdings records? NO, only MARC Bibs/Instances. abreaux reviewed with kgambrell for SRS MARC holdings and related Inventory Holdings. This is not happening for them.
- Do we know if it will affect Inventory Authority and SRS MARC Authority? NO, it should not. FOLIO is not yet creating authority records in MODINVSTOR, so only 999 ff $s so far. Once that starts to happen (likely in Lotus), kgambrell will ensure that the Inventory Authority and MARC Authority are assigned different UUIDs and that the 999 is constructed properly.
This issue occurs in bugfest juniper and bugfest kiwi environments. It has also been replicated in TAMU's local Juniper HF1 environment. Anecdotally, Cornell reports that it appears to have been happening since Iris HF3. When a record is created via data import OR single record import, the 999 field $i and $s uuid values are identical. Also checking *_mod_inventory_storage.records_lb table, instance_id = matched_id.
Steps to Reproduce:
- Create a record via single record import OR data import
- Access the newly-created record in the inventory app
- Click view source to see the values in the 999 field
999 $i (uuid to identify instance) and $s (uuid to identify marc srs record) are different