Transferring items with monographic parts to a new bib record causes problems with holds placement
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This was tested on Evergreen 2.1.1
On records with monographic parts, we've seen intermittent problems where the system seems to be displaying duplicate or incorrect parts at holds placement, even after all parts have been removed from the bibliographic record. I believe I've traced it to a problem that occurs when an item with parts is transferred from one bibliographic record to another and perhaps when two records are merged.
As an example, let's say you have a record for Compton's Encyclopedia with v. 01, v. 02, v. 03 as the parts and another record for the World Book Encyclopedia with vol. 01, vol. 02, vol. 03 as the parts. A cataloger adds an item to Compton's Encyclopedia with v. 01 as the part and then realizes it's on the wrong record and transfers it to the World Book Encyclopedia record.
If you look at the monographic parts by going through the "Manage Parts" screen for the World Book Encyclopedia, you will see vol. 01, vol. 02, vol. 03 listed because this interface is displaying parts associated with that particular bib record. However, if a user places a hold on World Book, the monographic part selector will list the parts associated with each item on the record and will consequently list vol. 01, vol. 02, vol. 03 and v. 01. If the user then places a hold on v. 01, the hold will actually show up as being for Compton's Encyclopedia since this is the record for which the monographic part was originally created.
Also, if you try to edit the record for the copy that was transferred, it will not display any of this parts information, which makes it very difficult for staff to correct the problem.
Changed in evergreen: | |
status: | New → Incomplete |
Changed in evergreen: | |
status: | Incomplete → Triaged |
Changed in evergreen: | |
assignee: | nobody → Dan Pearl (dpearl) |
tags: | added: parts |
For reference, running this query in a copy of our production data:
SELECT monograph_ part bmp ON acpm.part = bmp.id
bmp.id AS part_id, bmp.record AS part_record, acn.record AS cn_record
FROM
asset.copy ac
JOIN asset.call_number acn ON ac.call_number = acn.id
JOIN asset.copy_part_map acpm ON ac.id = acpm.target_copy
JOIN biblio.
WHERE
NOT ac.deleted
AND acn.record <> bmp.record
Gives me 37 rows. 34 if I add a distinct on bmp.id, 19 if I distinct on the combination of the two record IDs.