No warning provided when bib records with holds are deleted

Bug #1398107 reported by Michele Morgan
70
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.6
Fix Released
High
Unassigned

Bug Description

When attempting to delete a bib record with holds, the staff user should be given a warning if any active holds related to the bib record exist. The staff user should be given the option to abort the deletion of the bib record.

Use case:

With org unit settings as follows:

Delete volume with last copy: TRUE
Retain empty bib records: FALSE

Bib records will automatically be deleted when the last copy is deleted.

No warning is provided if holds exist on the title. Any holds are automatically cancelled and are given a cancel reason of "Untargeted Expiration". Cancellation of these holds is invisible to the staff user.

A warning that holds exist on the bib and option to abort would allow the staff user to preserve the holds while a replacement copy is purchased, transfer the holds to another title, or otherwise deal with the holds appropriately.

Revision history for this message
Andrea Neiman (aneiman) wrote :

Confirmed, still seeing this in 2.12.3 (web client)

Changed in evergreen:
status: New → Confirmed
tags: added: cataloging holds
Revision history for this message
Tiffany Little (tslittle) wrote :

We've recently realized this is happening, and it's a problem for us. For Acquisitions, we move Acquisitions copies to an alternate record rather than overlaying. So when holds exist on an autogenerated record and we move ACQ copies elsewhere, the holds are immediately cancelled. Even if that wasn't our workflow, having holds get auto-cancelled with no warning and no buffer time so you could undelete or whatever, seems not to be a great policy.

Revision history for this message
Chris Sharp (chrissharp123) wrote :

Setting to high priority since this directly impacts patrons with on-order holds.

Changed in evergreen:
assignee: nobody → Chris Sharp (chrissharp123)
importance: Undecided → High
Revision history for this message
Chris Sharp (chrissharp123) wrote :

I have a working branch that I'd like some experienced eyeballs on:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1398107_alert_when_dying_bib_has_holds

I add a new overrideable event that alerts the user when they are deleting a bib record. Also, I think it's prudent to retarget any title holds to the destination bib when doing a volume transfer and the source bib runs out of volumes.

Revision history for this message
Elaine Hardy (ehardy) wrote :

It would also be prudent to have a setting automatically transfer all holds, regardless of type when merging bib records as well as a warning the holds exist. Giving the cataloger the option to transfer holds or cancel the merge would be a good thing.

Revision history for this message
Chris Sharp (chrissharp123) wrote :

I have updated the working branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1398107_alert_when_dying_bib_has_holds

I have added a heading to the generic alert that may need some additional styling and it is currently not i18n-aware. Hopefully someone with chops can review.

Revision history for this message
Chris Sharp (chrissharp123) wrote :

BTW, my branch is *only* adding an alert at this point. I would recommend additional functionality requests going into a separate bug report.

tags: added: pullrequest
Changed in evergreen:
assignee: Chris Sharp (chrissharp123) → nobody
milestone: none → 3.6.1
Changed in evergreen:
assignee: nobody → Rogan Hamby (rogan-hamby)
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

Works as expected, sign off at user/rogan/lp1398107_alert_when_dying_bib_has_holds_signoff

Changed in evergreen:
assignee: Rogan Hamby (rogan-hamby) → nobody
tags: added: signedoff
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Revision history for this message
Jason Stephenson (jstephenson) wrote :

Works for me with production data on Evergreen 3.6.1. I signed off and pushed the fix to master and rel_3_6.

Thanks, Chris, Rogan, Michele, Elaine, and Tiffany!

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
milestone: 3.6.2 → 3.7-beta
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.