Issues that need RM SIG review.
- ability to manage relationships between other apps when holdings/items are moved:
- Is the expectation that the order info is to be updated to reflect current situation in inventory
- question from chat (What are the scenarios where items are moved between instances?)
- Mostly about ongoing orders
- want to prevent errors
- say, changing an order to online only, but that relationship and history will want to be kept to keep the history together (say, or payments) <unless a new order is created, while the existing one is closed>
- also edition changes
- plan for showing order info in item records (UX prod 1995)
- should info be display only (UX prod 1925)
- keep holdings UUID in the POL, which allows for some kind of relationship to be maintained even if an item does not exist
- Orders has the reference
- displayed in an accordion
- not synced, but display-only from where it is actually stored
- the internal linking vs populating info from one app to another
- we won't necessarily want that editable or stored, but displayed and linked
- Dennis B (example)
- looking at a new order
- to show links between orders and items
- IN inventory, one can move holdings and items
- if a holding is moved, the order still links to the instance, the pieces link to the items, but after the demo, the PO is split across 2 Instances
- In many cases though, an empty instance record would be deleted
- example of Serial title changes, thus a new record should have been created, but was not brought in, then barcodes will need to be moved to the new title when the new record comes in
- Charlotte asks: how to we expect the system at large to work?
- question from chat (What does moving represent though? Is it just a reorganisation of system pointers? )
- also from chat (Or is there a real world “move” that we are reflecting)