Angular Staff Client meta-Search with 1 metarecord fails to load items

[Steve Callender]

3.7

In angular, Admin > Search The Catalog,

It appears that if you have an item with only a single meta-record (it's easiest to test with title searches, since there might not be a lot of matching titles), the search goes through and takes you to the metarecord page but none of the items will display.

I tested this with a unique title that has 3 different bib types attached to it. When doing a search for this title and selecting "Group by Format/Editions" it showed no item results. Doing this same search on the OPAC/Boopac side, correctly returns results.

[Lindsay Stratton (lstratton)]

This also appears to happen in 3.6.5

Steps to duplicate:

1 - Search for a title with library location selected and Group Editions/Formats selected
2 - Search returned blank metarecord (navigation buttons, actions, tabs, etc. but no title details, URL ending: record/1674226/item_table?org=182&limit=10&query=dutch%20house&fieldClass=title&joinOp=&matchOp=contains&dateOp=is&groupByMetarecord=true&ridx=16)
3- Uncheck Group Editions/Formats, search again, valid results display

[Michele Morgan (mmorgan)]

I cannot reproduce this on a 3.7.2 system. I believe it was fixed in bug 1930088 and am inclined to mark this one as a duplicate.

I hesitate because Lindsay sees the problem in 3.6.5, which should contain the fix for 1930088. Do others see this issue in 3.6.5?

[Dan Guarracino (dguarracino)]

I also see this issue in 3.6.5.

I wonder if this behavior may be caused by the fix for 1912852?

When a metarecord search in the Angular catalog returns multiple results, the URL points to:
eg2/en-US/staff/catalog/search
and also includes the parameter:
&groupByMetarecord=true

After selecting a metarecord, the Angular catalog shows the search results for bib records that are components of the metarecord. The URL base stays the same as the search, but with an added parameter:
&fromMetarecord=[metarecord ID number]

When a metarecord search in the Angular catalog returns only one result, the URL points to:
eg2/en-US/staff/catalog/record/[metarecord ID number]

This is the URL for a bib record, so I think that the Angular catalog is trying to treat the metarecord ID as if it's a bib record ID when there's just the single result for the metarecord search.

[John Amundson (jamundson)]

I believe we are seeing this in 3.7.2 ,as well. I also believe this is due to the fix in LP #1912852.

Dan gives a good description.

When a metarecord search produces one result, it tries to go directly to the record. But it's using the ID field in metabib.metarecord, which isn't a bib ID at all. In our system, this can lead to some unexpected results.

We had a library report they tried to group formats/editions for a book about Muhammad Ali. When they executed the search, they were taken directly to a deleted record for a diet recipe book.

Ideally, when a Metarecord search is performed, the fix for LP #1912852 should not be honored, and the search results should simply display.

[Galen Charlton (gmc)]

A patch is available in working/user/gmcharlt/lp1949214_single_hit_metarecord / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1949214_single_hit_metarecord

Note that the caveat about not attempting the OPAC behavior of jumping on a metarecord search that returns one metarecord that has exactly one constituent doesn't reflect a fundamental limitation; it's just that implementing that behavior would require more adjustments to the Angular catalog search components and services than I have time for at the moment.

[Blake GH (bmagic)]

for rel_3_11:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/blake/lp1949214_single_hit_metarecord_rel_3_11

[William C. Szwagiel (wszwagiel)]

Evergreen version 3.11.1

I have performed some tests for the patch after Blake applied it to the Production environment in our version of Evergreen, and it appears to be working as intended.

[Andrea Neiman (aneiman)]

William, if you are willing to give this patch a signoff, please see instructions here under Sign-Offs: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing#overview

[Jane Sandberg (sandbergja)]

Thanks to Galen, all who helped to identify and describe this issue, William for testing, and Blake for the rel_3_11 patch. Pushed to rel_3_11 and above.