Purpose: When transferring holdings and items any existing relationships should be retained - https://docs.google.com/document/d/16iF5VxRPNVeVE7CVaLi8I9WYpz6RnYzE6iLUPvOCUA4/edit#heading=h.v4stg3pbhaa3
1) There is established relationship between a POL in the Order app, and a given holdings record via app interaction Order <>Inventory.
2) There is established relationship between a POL in the Order app, and a given item record via app interaction Order <>Inventory.
3) There is established relationship between a patron request and an item record in a holdings record. If the Item record is transferred to another holdings record, the Request link to the given item record must be retained.
4) Loans on a given item record is to retained, so the loan history is persistent (to be described further - Cheryl Malmborg , Holly Mistlebauer
The work is captured in:
Umbrella issue:
- UXPROD-1647Getting issue details... STATUS
Follow up work defined:
Jira | Product owner | Development team | Planned release |
---|---|---|---|
Thunderjet | None | ||
Thor | None | ||
Vega | None | ||
Vega | None |
Enable the user to delete an Instance.
Slide deck from an old UX presentation at MM-SIG 2018-10-04: https://docs.google.com/presentation/d/1iv1qM2T1uHCOx8vLAAJfmX-439ENNP7uo4yQJM8mubE/edit#slide=id.g438c473a97_0_0
Technical backend note: The Inventory database has constraints defined on Instance, HoldingsRecord and Item to prevent deletion of entities with dependent records. The database will throw an exception if such a delete is attempted, as a last backstop - see:
Tech lead documentation: Deletion of core-module records may leave dangling references from non-core modules
Complete list of use cases for when deletion of instances are relevant.
What do we mean with deletion of the instance:
The work is captured in:
- UXPROD-1624Getting issue details... STATUS
2 Comments
Dennis Bridges
Regarding the movement of inventory records: The following features were implemented to display related orders on Inventory records, UXPROD-2373, UXPROD-1995, UXPROD-3344. As of lotus they are all completed. The APIs used to retrieve order information for display might provide a simple mechanism for preventing users from moving records that have linked orders. This would be a first step in preventing issues from occurring. These APIs also provide order data that could be displayed to show users specifically what orders/order lines are preventing them from performing this action. There is a good chance that this type of implementation could be achieved with only UI resources.
Regarding the deletion of instances: UXPROD-3619 is being implemented for Morning Glory and it aims to allow users to easily change the relationship between a POL and an instance. If an instance was deleted this would at least give the user a way to link the order to a new instance. Also if inventory where to prevent deletion using a similar method to what is mentioned above then users would have a way of changing the instance connection of a POL so that they could ultimately delete the instance it was originally linked to.
The Thunderject team has also implemented Kafka on the order side as a part of delivering these features. So there is likely less work to be done if it is decided that this issue should be resolved using the messaging architecture. However, this would obviously require BE resources.
Khalilah Gambrell
Hey Charlotte Whitt - are there requirements created for when