Inventory
(UXPROD-785)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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:
Usecases: 2)
The jira feature was also mentioned in: 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 |
| Comment by Charlotte Whitt [ 08/Apr/20 ] |
|
The work planned for
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:
This require: CC: Felix Hemme lew235 |
| Comment by Charlotte Whitt [ 04/Nov/20 ] |
|
Hi Stephanie Buck Cate Boerema - when the Firebird team worked on
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. |
| 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:
|
| Comment by Cate Boerema (Inactive) [ 05/Nov/20 ] |
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 (
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.
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
|
| Comment by Cate Boerema (Inactive) [ 05/Nov/20 ] |
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:
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:
Data element change triggers:
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 |
| 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.
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
|
| Comment by Charlotte Whitt [ 10/Mar/21 ] |
|
Hi Jacquie Samples - I think I can explain the Jira history: The work done on
Then later this work was redefined, and retrain of relationship was defined as it's own feature (
Then later again Cate wanted dependency for each App / each record type to be spilt out as their own features, and I think
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 (
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 - Any other app or PO I am not thinking of? 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
Loans Orders - filed bug
Courses - filed bug
Fees/fines - filed
Patron notices |
| 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
|
| 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 |