Move holdings and item

Purpose: When transferring holdings and items any existing relationships should be retained - https://docs.google.com/document/d/16iF5VxRPNVeVE7CVaLi8I9WYpz6RnYzE6iLUPvOCUA4/edit#heading=h.v4stg3pbhaa3

Use cases


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 


Jira

The work is captured in:

Umbrella issue:

UXPROD-1647 - Getting issue details... STATUS

Follow up work defined:

JiraProduct ownerDevelopment teamPlanned release

MODORDERS-642 - Getting issue details... STATUS

ThunderjetNone

UICR-125 - Getting issue details... STATUS

ThorNone

UIREQ-589 - Getting issue details... STATUS

VegaNone

UIU-2082 - Getting issue details... STATUS

VegaNone


Deletion of instances

Purpose

Enable the user to delete an Instance. 

  • the user can be a person (a cataloger)
  • the system (bulk edit) 
  • other operations?

Expected behavior

  • Deletion of instances should follow a UX consistant behavior with deletion of other record types like holdings, item, and also other record types in other apps in FOLIO.
  • (Where have we implemented deletion of record types? Question to POs)


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 documentation

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:

  1. InstanceStorageAPI.java

Tech lead documentation: Deletion of core-module records may leave dangling references from non-core modules


Out of scope

  1. Prevent delete-all (wipe all data in Inventory).


Use cases

Complete list of use cases for when deletion of instances are relevant.


Topic for the group to discuss:

What do we mean with deletion of the instance:

  1. Will the instance be deleted from the database?
  2. Will the instance stay in the data base but flagged as a deleted record (can the instance then later be retrieved again, if the user regret the action, and want to roll back the deletion)?
  3. Will FOLIO offer the implementing libraries to choose the wanted behavior - so either solution 1) or 2)?


Jira

The work is captured in:

UXPROD-1624 - Getting issue details... STATUS


  • No labels

2 Comments

  1. 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.

  2. Hey Charlotte Whitt - are there requirements created for when 

    • To hard delete an instance?
    • To soft delete an instance? 
    • To prevent deletion of an instance?