Create via Data Import in Kiwi. With Lotus the MARC holdings record can be created directly from Inventory.
Edit in QuickMARC
View in Inventory, and locked if source == MARC
Relationship between FOLIO and MARC holdings are established
Field 001 and 004 are configurable with respect to the data from the Inventory HRID. Field value in the Holdings record > 004 is the HRID of the linked instance record
If holdings get moved to another instance record, the value in 004 is updated
Questions:
Will there be holdings properties we still can maintain in Inventory holdings (when there is an underlying MARC holdings); e.g. statistical codes, and suppress from discovery? → Yes, like with the Instance record.
Is the 999 ff $s the uuid for the MARC SRS bib or the MARC SRS holding? → It is the Holdings UUID.
Will the access to MARC holdings related actions be governed by permissions? So libraries who do not use MARC holdings, will not see any action buttons, or other options - while this is not needed if they only use Inventory holdings (with no underlying MARC holdings) → Yes, the known permissions (view, edit, delete)
What is the planned connection between MARC authorities and Instance records? → Needs to be discussed, not in Scope for Lotus.
is there a list somewhere of which apps will use elastic search? → So far only Inventory and Authority Search. The RM group has done some UX mockups but has not decided yet to implement as far as MM knows
What about Modules that pop up that interact with Inventory? → Needs discussion, postponed
A delete tag is added to instances that should be deleted by the catalogers
They use Bash scripts that are automated via a Cron job on a Linux server
Step 1: Retrieve instance records by tag, retrieve attached holdings_ids, retrieve attached item_ids
Step 2: Delete items, then holdings, then instances
SRS records can't be deleted. After a delete request the status changes from ACTUAL to DELETED
Note Ann-Marie: "I'll check with the SRS devs about the API documentation"
Is there a check in place that validates something like an item status == "checked out"?
Instance record is set to "suppressed" and then tagged
Just a few instances have items associated that could be potentially be checked out
Another issue could be if the instance record is linked from a POL in the Orders app
Comment from Jessica: "There is definitely a use case for wanting to keep an order/pol but delete the instance. Like if you withdraw something and don't want the bib cluttering up the database, but need to keep the order for accounting purposes."
uChicago has a similar workflow with Kuali OLE: They add a tag in a 9XX field ("delete"), and then run a report that checks on dependencies before the record is deleted in the database
Q from Sara: "Do we know if we delete and Item that was created by a Piece, will ONLY the item be deleted and NOT the Piece as well?" → A-M: "Hi Sara - I think it's worth testing. I don't think deleting the item will delete the piece. But the opposite may happen - orders does some cleanup in Inventory when orders/pieces are deleted"
From Jessica: "being able to report out (ie identify) the dependencies is really 90% of the battle"
From Laura: "agreed, Jessica -- and controlling how the tagging to be deleted happens accordingly. we are using a statistical code to mark records that potentially should be deleted, but not all have been vetted for potential dependencies."
Feature in Jira: UXPROD-1624 Deletion. Implement action menu in top navigation bar. Enable the user to delete a metadata record (Instance) - is P2. New approach: Set as Folio wide theme. Is also a topic in the App Interaction SIG.
Instead of hard delete in the database just hide records? There is a permission "staff suppressed" that matches the checkbox in the records.
Q from Lisa F: "So what if I made a mistake, (or we found the book that was lost for 20 years.): can I put them back or do I reimport? Just curious..."
Future topic idea: Present on batch updates with Shell scripts. This could be a topic for the API lab