Detailed search results shows parts for items that dont have parts

[Blake GH]

The best way I can describe this is by sharing some links:

This will show 2 results. The second bib does not have parts however the OPAC says it does.

http://mig.missourievergreen.org/eg/opac/results?detail_record_view=1&query=orange+is+the+new+black&qtype=title&fi%3Asearch_format=dvd&locg=174&sort=&detail_record_view=1

You can verify that by using this link:

http://mig.missourievergreen.org/eg/opac/results?query=orange+is+the+new+black+season+two&qtype=title&fi%3Asearch_format=dvd&locg=174&sort=&detail_record_view=1

This is the same search but this time narrowed the search to "Season two" and we only get one result (the same bib as the second result from the first link)

Here you can see that the item does not have parts.

The OPAC is getting the variable from args.holdings which comes from get_marc_attrs.

Somehow the parts "bleed" from one bib to the next under some circumstances.

[Thomas Berezansky (tsbere)]

Could the copy on the second bib have a part owned by the first bib? Sometimes when copies are moved from bib to bib the parts stay attached even though the bib is wrong.

[Blake GH (bmagic)]

There are zero rows in asset.copy_part_map for the item showing "Disk 2" on the second bib (1399132). There are zero rows in biblio.monograph_part for record 1399132

[Blake GH (bmagic)]

There are zero rows in asset.copy_part_map for the item showing "Disk 2" on the second bib (1399132). There are zero rows in biblio.monograph_part for record 1399132

Another clue that I realize, there is a "Disk 2" on the first bib but the copy is OPAC invisible. It belongs to a copy that is not showing here. I believe that somehow that opac invisible copy part is getting attached to the next visible copy.

[Blake GH (bmagic)]

Aha! Found it

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

[Ben Shum (bshum)]

Pushed to master and backported to rel_2_9 and rel_2_8. Thanks Blake!