Inventory
(UXPROD-785)
|
|
| Status: | Blocked |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | TBD | Parent: | Inventory |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Charlotte Whitt | Assignee: | Ryan Taylor |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | cataloging, delete_record_functionality, epam-folijet, inventory, metadatamanagement, po-mvp, round_iv | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Release: | Not Scheduled | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Inventory | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimate: | Small < 3 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimator: | Charlotte Whitt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Sergiy Sergiyenko | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Medium | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | Small < 3 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Niels Erik Nielsen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | The estimate considers data integrity checks and mark-for-deletion functionality. Hard to say how much these are general issues (solved in Raml Module Builder and stripes-components for example) and how much they are Inventory work | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Folijet | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 29 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 127 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Ranking Note: | CW: Deletion of holdings and item records are implemented, but not yet for instance records while it was not requested by Chalmers | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: St. Michael's College (Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Warner (MVP Jul 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Implement component in top navigation bar. Enable the user to delete a metadata record (Instance) Slide deck from 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: https://folio-org.atlassian.net/wiki/display/DD/Deletion+of+core-module+records+may+leave+dangling+references+from+non-core+modules Out of scope:
Implications for other apps (with related POs)
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 26/Aug/19 ] |
|
Hi Charlotte Whitt. Is this feature Analysis complete or do you expect to need to write additional stories? |
| Comment by Cate Boerema (Inactive) [ 17/Dec/19 ] |
|
Charlotte Whitt Is this feature Analysis complete or do you expect to need to write additional stories? |
| Comment by Charlotte Whitt [ 17/Dec/19 ] |
|
Cate Boerema
|
| Comment by Holly Mistlebauer [ 17/Jun/20 ] |
|
Chicago comment from Round IV Outliers spreadsheet: If we can delete via the API we can implement a daily batch process. -Tod Olson |
| Comment by Cate Boerema (Inactive) [ 09/Oct/20 ] |
|
Bohdan Suprun and Sergiy Sergiyenko can you please review and re-estimate this feature (if needed)? If you have questions, Charlotte Whitt should be able to answer. |
| Comment by Bohdan Suprun (Inactive) [ 09/Oct/20 ] |
|
Hi Charlotte Whitt, Is it about removing instances that do not have holdings and items associated? There are also more foreign keys for an instance that prevents removal even though there are not holdings and items associated:
What is expected when there will be a relationship or title? Note: There is already a removal endpoint, so there might be no BE work required depending on the answer to my last question. UPD: I agree with the current estimate in 3 days. |
| Comment by Sergiy Sergiyenko [ 09/Oct/20 ] |
|
Hi Charlotte Whitt, Cate Boerema. From the FE side, in the scope of this feature it requires to implement:
It can take up to 10 days. |
| Comment by Charlotte Whitt [ 09/Oct/20 ] |
|
Hi Bohdan Suprun and Sergiy Sergiyenko - thanks for being so quick with the estimats Re.:
If there is a relationship, e.g. instance to instance relationship, then the given instance can be deleted, but the data should be kept, but unlinked, when the related instance is not deleted. Let me update
|
| Comment by Bohdan Suprun (Inactive) [ 09/Oct/20 ] |
|
Instance relationship has only 3 properties right now - parent instance id, child instance id and relationship id. Do you mean that we should be able to add an 'unconnected' instance relationship, as we have for the titles when we may not specify preceding or succeeding instance id but instead we should provide title, HRID and identifiers? If we keep existing structure but just be removing parent/child instance id it is the same as remove the link at all. |
| Comment by Cate Boerema (Inactive) [ 12/Oct/20 ] |
Charlotte Whitt, are you saying that, when a connected preceding or succeeding title is deleted, we should first copy the metadata from it and create an unconnected one? Something like this: If so, we might want to break that into a separate feature. I like the idea of keeping this one simple, especially if it can be ui-only (as Bohdan Suprun said earlier that the endpoint is already there for deletion, there may not need to be back end for this). Thoughts? |
| Comment by Lisa Sjögren [ 02/Nov/20 ] |
|
Hi! Speaking as a librarian at an institution that's been using FOLIO in production for over a year, it would be so useful to be able to be able to delete instances, at the very least ones without any dependencies to other records, in the UI. (ping Marie Widigson, here'as the UXPROD for this) |
| Comment by Charlotte Whitt [ 02/Nov/20 ] |
|
I agree, Lisa Sjögren |
| Comment by Ann-Marie Breaux (Inactive) [ 27/Jan/21 ] |
|
Hi Charlotte Whitt It might be time to talk about this again. What do you think about putting it on an upcoming MM SIG agenda? Even if we only mark for deletion, or do a soft delete of the Instance. Whatever we do for the Instance, we probably? want to do the same thing to any related SRS MARC. Let me know how you want to proceed, and I'll aim to coordinate the Data Import functionality with the Inventory functionality, cc: Khalilah Gambrell Since whatever delete process we use for SRS MARC, we'll want to do the parallel thing for SRS Authority records. |
| Comment by Charlotte Whitt [ 27/Jan/21 ] |
|
Ann-Marie Breaux - I suggest that we before presentation for the MM-SIG then you, Owen Stephens Dennis Benndorf and I - in the light of today's conversation at the App Interaction meeting - make sure we have a thoroughly work ready uncovering dependencies across apps, which we then will review, and get the feedback and input from the SMEs. I'd also like for us to try if we can coordinate all relevant features for all our apps. So we can get the work planned well across apps, and avoid the risk that e.g. all work is dev ready for Inventory, and it is scheduled to be done in one team, but dependent work can not be done in another team. That's a bit how the work on move of holdings and items ended up being, where we did the work in Inventory (
It will be good to have this conversation soon, if we are aiming for maybe R2 2021 |
| Comment by Ann-Marie Breaux (Inactive) [ 28/Jan/21 ] |
|
Hi Charlotte Whitt I agree it would be good to have the conversation soon, especially if Core fxn may take this into R2 development, Like you say, that would require several of us working on other apps to do related work in our apps in R2, or else risk getting out of sync with the Inventory capabilities. This week and early next week are really bad for me. Maybe for now, we could at least add some "Implications for related apps" in the description as a starting point? |
| Comment by Owen Stephens [ 28/Jan/21 ] |
|
Thanks Charlotte Whitt. We don't have any direct links from Agreements or Licenses to Inventory right now, BUT we do have direct links to POLs and if a linked POL has an Inventory Instance UUID stored with it we display that as a link to the instance in Inventory. |
| Comment by Dennis Bridges [ 28/Jan/21 ] |
|
Charlotte Whitt and Owen Stephens This seems like another perfect use case for the argument that apps should keep track of UUIDs that they have deleted. Such that if another app were to ask for it that information could be provided and use however the other app deemed appropriate. The POL does contain a ref to instance and if it were deleted the POL data would remain in tact. However, Receiving would be impacted as orders could no longer create items successfully. Ultimately we plan to allow user to change the instance link which would help resolve this. In the mean time the order would need to be closed. cc: Ann-Marie Breaux |
| Comment by Lisa McColl [ 31/Jan/21 ] |
|
This is probably covered above, but in case, it would be a nice feature to either have an alert or to block the deletion of a record with a PO linked to it at all. Maybe the PO could have a particular "state" in order for deletions to be successful, not just closed. Also, it really is more relevant for the PO to be linked to a holdings record - for those who are not using item records in the case of e-resources, and linked to the item when items are used. That depends on the institutions' setup. The PO to an item relationship, back and forth is important for statistics (money spent to usage). |
| Comment by Ann-Marie Breaux (Inactive) [ 01/Feb/21 ] |
|
Hi Lisa McColl Good point - keep in mind that if an instance has an existing holdings or item, the instance cannot be deleted. I think |
| Comment by Lisa McColl [ 01/Feb/21 ] |
|
Thank you Ann-Marie Breaux. That does cover the worst of the concern. However, you're right that the path to the actual item that was paid for would be broken if there is not something keeping that connection to the holding or item. |
| Comment by Ann-Marie Breaux (Inactive) [ 04/Nov/21 ] |
|
Per Charlotte Whitt, feature is blocked due to Data Sync working group, and potentially wanting to work on an overall theme of deletion. |
| Comment by Marie Widigson [ 11/Feb/22 ] |
|
Regarding the PO ranking note above "CW: Deletion of holdings and item records are implemented, but not yet for instance records while it was not requested by Chalmers" Chalmers just wants to clarify that this was a remark from hard prioritizing back in 2019. We of course find it necessary to be able to delete instance records through the UI. |