Merge monograph parts should transfer holds to resulting part

Bug #1533316 reported by Michele Morgan
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

Evergreen 2.9.1

This report is related to https://bugs.launchpad.net/evergreen/+bug/1406786

When merging monograph parts, multiple part entries can be selected and merged to the chosen prevailing part. All copies are then properly mapped to the chosen prevailing part and the non-prevailing part(s) are flagged as deleted.

If there are part level holds on any of the non-prevailing parts, they are not moved to the prevailing part. Instead, they remain on the parts that are now flagged as deleted. These holds will never be filled since all the copies have been remapped to the prevailing part.

When parts are merged, any part level holds on non-prevailing parts should also be moved to the chosen prevailing part.

To reproduce/test:

Add parts to a bib record, for example, "v.1" and "Vol. 1"
Add a copy and assign the part "v.1"
Add a copy and assign the part "Vol. 1"
Place a part level hold on "v. 1"
Merge the parts "v.1" and "Vol. 1", choosing "Vol. 1" as the prevailing part

Note that part "v.1" now has its deleted flag set to TRUE, but its id remains the target of the hold.

tags: added: cataloging parts
Lynn Floyd (lfloyd)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Lynn Floyd (lfloyd) wrote :

We are still seeing this in 3.2.

tags: added: holds
Dan Briem (dbriem)
tags: added: circ-holds
removed: holds
Elaine Hardy (ehardy)
tags: added: cat-parts
removed: cataloging parts
Galen Charlton (gmc)
Changed in evergreen:
importance: Undecided → Medium
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.