Transferring items with monographic parts to a new bib record causes problems with holds placement

Bug #904472 reported by Kathy Lussier on 2011-12-14
50
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Evergreen
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.

Thomas Berezansky (tsbere) wrote :

For reference, running this query in a copy of our production data:

SELECT
    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.monograph_part bmp ON acpm.part = bmp.id
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.

Thomas Berezansky (tsbere) wrote :

I don't know how (personally) to move an item from one record to another without merging, but merging records was likely fixed by this bug:

https://bugs.launchpad.net/evergreen/+bug/849143

Changed in evergreen:
status: New → Incomplete
Changed in evergreen:
status: Incomplete → Triaged
Janet Schrader (jschrader) wrote :

If an item with a monographic Part is transferred without deleting the Part first the item will display in the OPAC twice, once for each Part but in holdings maintenance only the Part for the bib record to which the item is not attached will display. You have to delete the new Part if you added one; move the item back to the original record; delete the 'old' Part; retransfer the item to the new record. I wasn't aware that the Part from record A also moved to record B but we did find about 400 Parts on the wrong bibs. We noticed it when holds on one title were placed on a different one.
This appears to be fixed when merging records.

Dan Pearl (dpearl) on 2014-11-20
Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Jason Stephenson (jstephenson) wrote :

Dan if you want help with this let me know. Thomas Berezansky also has a query that can help identify these.

Changed in evergreen:
status: Triaged → Confirmed
Dan Pearl (dpearl) wrote :

Thanks for the offer of help. I had constructed a new API, but for some reason, it was not invoked. It's probably something simple that is keeping it from working. I'll post some code when I get back from a trip.

Remington Steed (rjs7) on 2015-10-07
tags: added: parts
Remington Steed (rjs7) wrote :

Hi Dan, do you have a branch ready to share for this bug?

Dan Pearl (dpearl) wrote :

I don't have anything for this, alas. Perhaps I can do some work on this during Hack-a-way.

Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Dan Pearl (dpearl) wrote :

Non-working version. Still need to be debugged and authentication added.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dpearl/partmove_904472

Remington Steed (and Dan Wells) are looking at this to help me get past my block on this. Other eyes welcome.

Kathy Lussier (klussier) wrote :

The code Blake contributed as part of bug 1411422 fixes this issue. I'm going to mark this bug as a duplicate so that all discussion can happen on the other bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers