Inventory (UXPROD-785)

[UXPROD-1647] Theme: Ability to maintain relationships between other apps when holdings/items are moved Created: 12/Apr/19  Updated: 06/Dec/23

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: TBD
Parent: Inventory

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Ryan Taylor
Resolution: Unresolved Votes: 0
Labels: PO-mvp, back-end, crossapp, delegate_candidate, epam-folijet, inventory, metadatamanagement, relink
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2020-04-08 kl. 10.00.47.png     PNG File Skärmavbild 2020-11-05 kl. 11.56.04.png     PNG File screenshot-1.png    
Issue links:
Defines
defines UXPROD-785 Inventory In Progress
is defined by UICR-125 Data corruption. When holding/item da... Open
is defined by UIREQ-589 [BE] Data corruption. When holding/it... Open
is defined by UIU-2082 [BE] Data corruption. When holdings/i... Closed
is defined by MODORDERS-642 Data corruption. When holding/item da... In Refinement
Gantt End to Start
has to be done after UXPROD-137 Move Holdings and/or Items Closed
Relates
relates to UXPROD-2373 Allow for the display of piece inform... Closed
relates to MODDATAIMP-399 SPIKE: Allow POL or Vendor Ref Number... Closed
relates to UXPROD-3342 Implement data consistency approach f... Closed
relates to FOLIO-1273 Define and describe the architecture ... Open
relates to UXPROD-3879 Implement data consistency approach f... Open
relates to UXPROD-3399 When Relevant User Record Attributes ... Draft
relates to UXPROD-3664 Future Fees/Fines: Add Loan Type and ... Draft
Release: Not Scheduled
Epic Link: Inventory
Analysis Estimate: Very Small (VS) < 1day
Analysis Estimator: Charlotte Whitt
Front End Estimate: Very Small (VS) < 1day
Front-End Confidence factor: Low
Estimation Notes and Assumptions: There may not be any work needed to retain the relation to Orders, ref the comment on this issue:

"Orders relate to the Inventory Item by this property on the Item

{code}
 "purchaseOrderLineIdentifier": {
      "type": "string",
      "description": "ID referencing a remote purchase order object related to this item"
    },
{code}

The Item in turn relates to a holdings record by an holdingsRecordId on the Item.

Moving the Item to a different holdings record is basically changing the ID - Orders' relation to the Item will be retained in that process and thus move along to the new holdings record with the Item."
Development Team: Folijet
Kiwi Planning Points (DO NOT CHANGE): 144
PO Rank: 111
PO Ranking Note: CW: Aligned PO rank with Calculated Total rank
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R1
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

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

Usecases:
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 - Emma Boettcher
5) ....

  • - - - - - - - - - - - - -

Usecases:
1) Holding, subscription, and item records move together. In all situations, when an item record is moved, the associated holding and subscription record should automatically follow so that there are no empty record lingering that could be accidentally found by a patron.

2) UXPROD-2268 Closed addresses - guidance for this question from Felix Hemme: Do you know how a transfer of holdings from one instance to another would work, if the change is triggered outside of Folio? Something to keep in mind with regards to UUID or HRID?

The jira feature was also mentioned in:
Gap Analysis 2019 Missing Features - https://docs.google.com/spreadsheets/d/1b3VY1EUOAyoySuEaT0lJfKUBYLMUPZM6PDSBnGiMxYk/edit#gid=739330010

Original order # 145



 Comments   
Comment by Anya [ 19/Apr/19 ]

FC: Must have for orders, Nice to have for the rest.

Comment by Niels Erik Nielsen [ 17/May/19 ]

Orders relate to the Inventory Item by this property on the Item

 "purchaseOrderLineIdentifier": {
      "type": "string",
      "description": "ID referencing a remote purchase order object related to this item"
    },

The Item in turn relates to a holdings record by an holdingsRecordId on the Item.

Moving the Item to a different holdings record is basically changing the ID - Orders' relation to the Item will be retained in that process and thus move along to the new holdings record with the Item.

Comment by Anya [ 10/Jun/19 ]

Hi Charlotte Whitt in the capacity plan this ticket is marked for "Fix Version/s: Q1 2020" Could I change this status on this ticket to reflect that?

Comment by Charlotte Whitt [ 10/Jun/19 ]

Hi Anya - yes please do. I'm not sure, who has added those fix versions ...

Comment by Cate Boerema (Inactive) [ 07/Aug/19 ]

Hi Charlotte Whitt I think loans and requests are associated with item IDs so I doubt there will be an issue there either. What confuses me about this issue is that you've marked it MVP yet I am not aware of any way to actually move items. How does one actually do that?

Comment by Felix Hemme [ 19/Sep/19 ]

The POL is linked to the Inventory instance and not to the Inventory item, right? We've only got one discrepancy in terminology. This is a screenshot from an POL:

However, moving an item while it is on loan will cause problems. This is because the loan status is hard-coded in the item's metadata. This leads to some issues if the items are managed by an external system such as our CBS union database. Transfers of items would be done there and updated to Folio Inventory. But the external system does not know the loan status.

"status" :

{ "name" : "Checked out" }

,

"status" :

{ "name" : "Available" }

,

Transfering an item to another holding record: https://drive.google.com/file/d/1uXhP7YqVIkNJoVZaL3HqZMvpJijZ2J86/view?usp=sharing
If "status" and "name" are deleted in the JSON, this leads to a NullPointerException.

Comment by Charlotte Whitt [ 08/Apr/20 ]

The work planned for UXPROD-1647 Open is to be incorporated into UXPROD-137 Closed - which means following dependencies to be addressed under the hood of UXPROD-137:

Ability to maintain relationships between other apps when holdings/items are moved from one instance to another, and Items (with all existing item states) can be moved:

  1. Request (also the Request statistics)
    • Item level request
    • Title level request
  2. Orders (this is important - will loop in Dennis. AppInteraction SIG - will loop in Martina Schildt)
  3. Existing loan, statistics for check out (Chalmers comment)
  4. MARCcat (check with Tiziana)
    • MFHD - moving holdings (Duke, Alabama ...)
  5. SRS (check with AM-B)
  6. Course Reserve (check with Kelly)

This require:
Review each item state, and make sure a correct context specific warning/action note etc. is populated, e.g. if the item is checked out, then a note for technical service staff

CC: Felix Hemme lew235

Comment by Charlotte Whitt [ 04/Nov/20 ]

Hi Stephanie Buck Cate Boerema - when the Firebird team worked on UXPROD-137 Closed (move holdings and item) then the work related to maintaining dependencies across apps like Orders, Request etc. was not included.

Last week we had a demo for EBSCO customers, and here we spend quite some time talking about especially the need for having the Order data to be updated and in sync with updates in Inventory - when move of holdings and item has been performed.

In that context I recommend that we re-open this feature, and discuss how to get the work prioritized.

CC: Anya Laura Daniels Dennis Bridges

Comment by Cate Boerema (Inactive) [ 05/Nov/20 ]

Thanks Charlotte Whitt. I am having a hard time understanding what isn't working. Could you please write up a bug describing that? We may end up changing the bug to a story, but I think that, to plan this work, we need to understand more specifically what the issue is.

Comment by Charlotte Whitt [ 05/Nov/20 ]

Hi Cate Boerema - it's not a bug, but work which has not been implemented yet.

I can forward to you the recording of the hands on session at the EBSCO Customer meeting last week in a PM.

So to explain the scenario we went through at the meeting:

  1. Create an order with POL, with holdings and item(s)
  2. Open the given order
  3. Go to Inventory, move the given item to another holdings OR move the given holdings and item(s) to another instance
  4. Go back to the Order app, verify if the move of item OR holdings+item is reflected in the Order/POL
Comment by Cate Boerema (Inactive) [ 05/Nov/20 ]

it's not a bug, but work which has not been implemented yet.

Thanks Charlotte Whitt. That's why I said we might need to change the bug to a story. I was really just looking for more specifics regarding what was not working as expected. Thank you for providing that in your comment.

I haven't actually had the chance to test/observe the orders issue you describe but I am guessing it is caused by the classic cross-app synch issue we have across FOLIO. Since FOLIO is microservices-based (as opposed to a relational DB) data doesn't automatically synch across apps. I have been told that making this happen is a non-trivial change that would require the use of Pubsub. I have two tech debt items in Core Functional's backlog related to synching between Requests and Users ( FOLIO-2473 Closed ) and Requests and Items ( UIREQ-650 Open ). I know Kelly recently created a feature for a similar issue in Courses: UXPROD-2594 Draft

I am not sure that we should just re-open this UXPROD. I think more specific issues might be appropriate, instead. It seems to me like the first step should be for POs whose apps interact with items should test the impact of moving them on their apps. That would be:

Does that make sense to others?

FYI Marc Johnson

Comment by Charlotte Whitt [ 05/Nov/20 ]

Sure we can split the feature into relationship with each app.

Re.

Any other app or PO I am not thinking of?

Then I can think of:

Comment by Kelly Drake [ 05/Nov/20 ]

Cate Boerema - Testing, and documenting actual impact of moving items makes sense. Although I'm not clear where we are documenting that - in specific jira's or in one joint jira/document?

Also---The same lack of an ability to maintain relationships also occurs with Users. Course has created https://folio-org.atlassian.net/browse/UXPROD-2747 to document the issue. But it's going to occur in other apps as well so we might want to tackle that with the item issue?

Comment by Charlotte Whitt [ 05/Nov/20 ]

Cate Boerema - I suggest that we keep UXPROD-1647 Open (which is ranked of all libraries as R1 - except for Cornell (R4) and Chalmers (R2)). The specific stories for each area defining this feature can be linked up to UXPROD-1647 Open . This feature then document and capture, that all relevant dependencies are documented, and work needed is In progress.

Comment by Cate Boerema (Inactive) [ 05/Nov/20 ]

I suggest that we keep UXPROD-1647 Open (which is ranked of all libraries as R1 - except for Cornell (R4) and Chalmers (R2)). The specific stories for each area defining this feature can be linked up to UXPROD-1647 Open . This feature then document and capture, that all relevant dependencies are documented, and work needed is In progress.

Why don't we start by asking the POs to write issues for any problems they identify in their applications. We can link them here as related. Once we know what work needs to be done, we can decide whether we re-open this UXPROD or create separate ones. The reason I'm leaning towards separate features is that I suspect that that several teams may have work to do in their own apps.

Comment by Dennis Bridges [ 05/Nov/20 ]

I'm sure this will affect us as we link the POL to an instance but the Piece within the POL links to an item. I'll see if I can make time for thunderjet to consider the consequences.

Comment by Cate Boerema (Inactive) [ 06/Nov/20 ]

Hey POs. I created a document for capturing test results here: https://docs.google.com/spreadsheets/d/1OiZKLtk8i-YCF6K5PoB9aCgm5liLtBC5IHnDzUvu28E/edit#gid=0

I tested Requests found that the effective location, effective call number and contributor are all being kept in synch through the moves. Only the Title is not. I augmented my existing tech debt issue with this information: https://folio-org.atlassian.net/browse/FOLIO-2474

FYI Charlotte Whitt

Comment by Cate Boerema (Inactive) [ 09/Nov/20 ]

Hi guys. I had a chat with Marc Johnson about how we should structure this work and this is what I learned:

  1. There will need to be some work in Inventory to broadcast the changes. So we'd need one UXPROD feature for Core Functional for this. We could use this one for that, but the description would need to be updated significantly.
  2. There will need to be some work in each app to react to the changes. So we'd probably need one UXPROD feature for each app whose Inventory data can get out of synch. For Requests, for example, we could convert (or clone) UIREQ-650 Open into a feature.

In order to ensure that the work done in Inventory is testable, we'd want to prioritize at least one of the app reaction features in the same development period.

To properly design the broadcast mechanism, we need to collect all the inventory data that is getting out of synch by application. Then, for each data element that can get out of synch, we should articulate all the ways that can happen. For example:

App elements that can get out of synch with Inventory:

  • Requests:
    • Item barcode
    • Item's (instance) title
  • Orders:
    • ?
  • Courses:
    • ?
  • Other?

Data element change triggers:

  • Item barcode
    • Edit barcode via item record edit page
    • Edit barcode via Data import
    • Edit barcode via receiving
    • Edit barcode directly in storage
  • Item's (instance) title
    • Edit title via instance record edit page
    • Edit title via Data import
    • Move item's holding from one instance to another
    • Move item from one instance to another
    • Edit directly in storage

Charlotte Whitt, do you want to reuse this feature for the work needed in Inventory? If so, I can adjust the summary and description accordingly.

Comment by Dennis Bridges [ 19/Nov/20 ]

Charlotte Whitt I have done some testing here, moving items and holdings around that are connected to orders. At the moment the connection are maintained as they are stored in the order side. However, it does cause what might be considered odd behavior, if the user moves "On order" items before they are received. Perhaps we should discuss this in the app interaction meeting or with the RM SIG?

Comment by Charlotte Whitt [ 20/Nov/20 ]

Hi Dennis Bridges - yes, I think it will be good to raise the discussion in App Interaction and maybe also RM-SIG. The working group who did the spec of move of holdings and item did point out following dependencies: https://docs.google.com/presentation/d/1E_tCI2zwUnJi9cCEJ9JBPR0SDZ8Z-ivQb5IXK8vSdEs/edit#slide=id.g7f18bee7d3_0_108
And in an EBSCO customer meeting similar expectations for any move of holdings/item to be reflected with the associated order record.

CC: Martina.Schildt Kristin Martin Anya

Comment by Martina.Schildt [ 20/Nov/20 ]

Hi Dennis Bridges, Hi Charlotte Whitt, I as well think it would be good to raise the topic in both App Interaction and RM. As far as AI is concerned we could discuss this on Dec 16. Should we have an RM discussion prior to that to gather SME feedback that we can include in an AI discussion Kristin Martin?

Comment by Kristin Martin [ 20/Nov/20 ]

Dennis Bridges Charlotte Whitt Martina.Schildt I was just reading this over this morning and have added it to the agenda for today's RM SIG meeting.

Comment by Charlotte Whitt [ 20/Nov/20 ]

Hi Martina.Schildt - sounds good.
Re.

gather SME feedback

Then maybe I don't think there is that much uncertainty about that SMEs expect that updates based on move of holdings and item within Inventory, are to be in sync with data populated in Orders. That was raised by the working group, and also at the EBSCO customer meeting.

But if you all think I'm jumping too fast to the conclusions, and is too focused on finding the best solution ... I'm fine too

One of the big questions we need to solve AI+RM is how do we establish a synchronous display of data, and would one way forward be, to only store the information in one app, and then display the data coming from that app in the other app - so Inventory -> Orders

Comment by Kelly Drake [ 02/Dec/20 ]

This probably effects Course Reserves as well. Updates based on move of holdings and item within Inventory, are to be in sync with data populated in Course Reserves.

Comment by Charlotte Whitt [ 03/Dec/20 ]

Hi Kelly Drake - yes Course Reserves is also listed as one of the apps where there will be dependencies. See the slide:

Comment by Jacquie Samples [ 10/Mar/21 ]

Is this really a duplicate with UXPROD-137 Closed ?   It appears to be the "front end" part of the "back end" request to retain relationships when moving holdings and items.  Can someone clarify, please?

Comment by Charlotte Whitt [ 10/Mar/21 ]

Hi Jacquie Samples - I think I can explain the Jira history:

The work done on UXPROD-137 Closed had originally the intention also to check for dependencies, and make sure, that transfer of holdings and items would retain even with a dependency, e.g. an order record.

Then later this work was redefined, and retrain of relationship was defined as it's own feature ( UXPROD-1647 Open ).

Then later again Cate wanted dependency for each App / each record type to be spilt out as their own features, and I think UXPROD-1647 Open was then closed. But it should not be closed, but kept as an Umbrella feature, so we can keep track, and not loose sight of any relevant dependency check.

Some how the linking to these features seem to have vanished (or the features was never written). Not sure what have happened, but I'll try to follow up with the relevant POs and see if we can get the features in and link to this umbrella issue.

Comment by Charlotte Whitt [ 10/Mar/21 ]

Cate Boerema added a comment - 05/Nov/20 11:29 AM

Thanks Charlotte Whitt. That's why I said we might need to change the bug to a story. I was really just looking for more specifics regarding what was not working as expected. Thank you for providing that in your comment.

I haven't actually had the chance to test/observe the orders issue you describe but I am guessing it is caused by the classic cross-app synch issue we have across FOLIO. Since FOLIO is microservices-based (as opposed to a relational DB) data doesn't automatically synch across apps. I have been told that making this happen is a non-trivial change that would require the use of Pubsub. I have two tech debt items in Core Functional's backlog related to synching between Requests and Users ( FOLIO-2473 Closed ) and Requests and Items ( UIREQ-650 Open ). I know Kelly recently created a feature for a similar issue in Courses: UXPROD-2594 Draft

I am not sure that we should just re-open this UXPROD. I think more specific issues might be appropriate, instead. It seems to me like the first step should be for POs whose apps interact with items should test the impact of moving them on their apps. That would be:

Requests - me (Cate Boerema) Brooks Travis
Loans - Emma Boettcher Cheryl Malmborg
Orders - Dennis Bridges
Courses - Kelly Drake
Fees/fines - Holly Mistlebauer
Patron notices - Darcy Branchini

Any other app or PO I am not thinking of?
Does that make sense to others?

FYI Marc Johnson

Comment by Jacquie Samples [ 11/Mar/21 ]

Hi Charlotte Whitt.  Thanks so much for your explanation and work on this.  I will put this back on our list of Jiras to consider in new capacity planning process.

Comment by Charlotte Whitt [ 23/Mar/21 ]

Documentation: https://docs.google.com/document/d/18aj_TXhweUAAhT9qMwrp6gK7q316RNYsXr8y11wWr90/edit#

Status for each dependent app:

Requests - filed bug UIREQ-589 Open Data corruption. When holding/item data are moved in Inventory, then the connected Request is not updated accordingly

Loans - All works excellent - the loan pages are updated accordingly

Orders - filed bug MODORDERS-642 In Refinement Data corruption. When holding/item data are moved in Inventory, then the connected Order lines are not updated accordingly

Courses - filed bug UICR-125 Open Data corruption. When holding/item data are moved in Inventory, then the item in Courses is not updated accordingly

Fees/fines - filed UIU-2082 Closed Data corruption. When holding/item data are moved in Inventory, then the connected Fee/Fine is not updated accordingly

Patron notices - this works as expected. Maybe further test in Iris Bugfest environment

Comment by Brooks Travis [ 13/Apr/21 ]

Should the resolution on this ticket be changed?

Comment by Charlotte Whitt [ 13/Apr/21 ]

It's an umbrealla issue. Cate misunderstood the ticket and took it for a duplicate. And now it can not be changed due to a Jira bug according to Holly Mistlebauer.

Comment by jackie.gottlieb@duke.edu (Inactive) [ 14/Apr/21 ]

Charlotte Whitt and Holly Mistlebauer, Duke has identified this one for voting but it is not currently on the Feature Pointing Ballot (I gather because it is set as a duplicate). What is the status of adding it to the ballot? Thanks.

Comment by Charlotte Whitt [ 15/Apr/21 ]

Hi jackie.gottlieb@duke.edu - thanks for spotting this.

Holly Mistlebauer - this ticket did Cate by mistake mark as a duplicate. You probably remember, that I asked if you as a Jira admin could change the status, but that was not doable due to a bug in jira.

FYI jackie.gottlieb@duke.edu - the planned work has been addressed in this doc: https://docs.google.com/document/d/16iF5VxRPNVeVE7CVaLi8I9WYpz6RnYzE6iLUPvOCUA4/edit#

Comment by Kristin Martin [ 15/Apr/21 ]

Where do we assign our points if we want the features described in this issue? Can we assign them to MODORDERS-642 In Refinement ? Or are we supposed to assign them to UXPROD-2373 Closed ? I'm worried that the description for the latter is not sufficient for people to understand that work on that issue will allow for acquisitions data to be updated if holdings and items are moved. It doesn't seem obvious to me.

Comment by jackie.gottlieb@duke.edu (Inactive) [ 15/Apr/21 ]

Thank you Charlotte Whitt, I am still not clear if this Jira will be added to the pointing list or if there will be another Jira that is added in its place. 

Comment by Ann-Marie Breaux (Inactive) [ 06/Dec/23 ]

Moved from Prokopovych backlog to Folijet Backlog cc: Ryan Taylor

Generated at Fri Feb 09 00:17:18 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.