Inventory (UXPROD-785)

[UXPROD-3621] Spec and planning. Inventory. Mark instance for deletion. 1st iteration. Enable the user to mark an instance for deletion Created: 24/Mar/22  Updated: 08/Jan/24  Resolved: 19/Oct/22

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Nolana (R3 2022)
Parent: Inventory

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: inventory, metadatamanagement, record_delete, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skærmbillede 2022-06-30 kl. 10.49.57.png     PNG File Skærmbillede 2022-06-30 kl. 10.50.15.png     PNG File Skærmbillede 2022-06-30 kl. 10.50.38.png    
Issue links:
Gantt End to End
has to be finished together with UXPROD-3092 Corresponding Data Import & SRS MARC ... Draft
Gantt End to Start
has to be done before MODINVUP-17 Make instance deletion aligned with g... In Progress
has to be done before UXPROD-3742 Mark instance for deletion. 2nd itera... In Refinement
Relates
relates to UXPROD-1363 Mark holdings and item for deletion. ... Open
relates to UXPROD-3702 Enabler : Marking an instance record ... Open
relates to MODINVSTOR-828 Change source record deletion documen... Closed
relates to UXPROD-1624 Deletion. Implement action menu in to... Blocked
Epic Link: Inventory
Analysis Estimate: Very Small (VS) < 1 day
Analysis Estimator: Charlotte Whitt
Front End Estimate: Small < 3 days
Front End Estimator: Michal Kuklis
Back End Estimator: Marc Johnson
Development Team: Prokopovych
Kiwi Planning Points (DO NOT CHANGE): 46
PO Rank: 88
PO Ranking Note: CW: Aligned PO rank with Calculated Total rank.
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R4
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R4

 Description   

The implementation of Mark for deletion work has been split into two iterations:

  1. UXPROD-3621 Closed (Spec and planning)
  2. UXPROD-3742 In Refinement (The actual work)

Implementation: In Edit view a toggle which enable the user to mark an instance for deletion. For this first iteration the permissions will be regular Edit. When we have defined the technical solution allowing us to do Field level permissions, then we can implement this granular level of permissions. Field level permissions are currently being discussed in the App Interaction SIG (CC: Martina.Schildt)

Delete functionality will be implemented when introducing the refined UX of Inventory. A drop down menu in the top bar.

Out put:

  1. Specifications
  2. Demo at WOLFcon: https://docs.google.com/presentation/d/1kp44JB0pOsiwvkDHWmqLvZWLbh0bd-9IWL_wf1hGP8k/edit
  3. Presentation for the MM-SIG https://docs.google.com/presentation/d/1ePfp0_fK1xW4mfpS6NRIkFwDQEyAvqMPTAlXI8hbxCI/edit#slide=id.g1364ff8ecb1_0_14

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

Out of scope: Prevent delete-all (wipe all data in Inventory). This functionality is used by SysOps doing migrations. The Core Platform is working on changing bulk deletion:



 Comments   
Comment by Marc Johnson [ 24/Mar/22 ]

Charlotte Whitt

I reviewed the attached slide deck. None of the content seemed to be to do with mark for deletion.

I also have some questions about this work.

Permissions are different than permissions for actual deletion.

Are the permissions different than for a general edit of the instance?

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

Given that this work is about marking the entry for deletion (and not deleting it) how are the constraints that impact deletion relevant for this work?

Comment by Michal Kuklis [ 28/Mar/22 ]

Charlotte Whitt I added the FE estimation. My understanding is that this option will be added to the existing action menu.

Comment by Marc Johnson [ 28/Jun/22 ]

In UIIN-1504 Open scenario 2 (quoted below) suggests that it will be possible to mark / unmark an item for deletion in the edit page for an instance.

The check box has the same inter-action as implemented when marking e.g. Suppress from discovery, and Staff suppress (= mouse over, activation, and selection)

In UIIN-333 Closed (quoted below) it seems that mark instance for deletion is an action. And that there is no way to unmark a record. This seems to be supported by the description in UIIN-1979 Blocked

Given a "Mark instance for delete" option in the actions drop-down

Charlotte Whitt Which of these (or both) of these UI designs are intended to be implemented?

Comment by Charlotte Whitt [ 28/Jun/22 ]

Marc Johnson - Ideally the MM-SIG SMEs would like to be able to select "Mark for Deletion" both in Instance edit mode and in detailed view.

This week I'll have continued talks with the SMEs to figure out if we must choose one, and then we most likely will choose the edit view, because this behavior is similar/related to suppressing a record.

As I said at yesterday's meeting I'll present the dev ready stories at our grooming meeting next week. So please for now, let's wait with further comments - https://folio-org.atlassian.net/wiki/display/FOLIJET/Prokopovych+-+Tickets+for+Grooming

Comment by Marc Johnson [ 29/Jun/22 ]

Charlotte Whitt

Ideally the MM-SIG SMEs would like to be able to select "Mark for Deletion" both in Instance edit mode and in detailed view.

Ok. How is it useful to users of the system to have two ways to do this?

I'm asking because that could have an impact on both the technical design and other parts of the behaviour.

The estimates provided for this feature, DO NOT include implementing both of these. I have removed the back end feature estimate until the expectations for the feature are better understood.

As I said at yesterday's meeting I'll present the dev ready stories at our grooming meeting next week. So please for now, let's wait with further comments

Ok. I do have follow up questions that could effect the scope and design of this work.

I disagree with waiting to ask them until we bring this to the team. I'd prefer to at least address the questions we know about before that.

However, I will respect your request here and not ask further. I do think this could delay our ability to start the work and could lead to confusion during development (which we know is disruptive).

This week I'll have continued talks with the SMEs to figure out if we must choose one, and then we most likely will choose the edit view, because this behavior is similar/related to suppressing a record.

How will you and the SMEs know whether they need to choose one?

Comment by Charlotte Whitt [ 29/Jun/22 ]

Marc Johnson - I'll invite you to my next check in with SME's tomorrow morning. All good?

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