Unexpected Journal Title Search Results when using second or third Search Input in Advanced Search

Bug #1522538 reported by Erica Rohlfs on 2015-12-03
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen Version 2.8.4

Evergreen only checks the first 'qtype' parameter when deciding whether to add the 'bib_level(s)' filter to the query. Or, the code adds a "bib_level(s)" to the search query to limit the results to serials only when "Journal Title" is the first selected search field.
This limitation causes unexpected search results when conducting a Journal Title search on either the second or third Search Input within Advanced Search.

To test, select a serial/magazine within your database. I chose "Urban Farm" in mine. If I filter on Journal Title and enter Urban Farm onto the first Search Input line, I retrieve the expected Urban Farm serial record. If I select Journal Title and enter Urban Farm into either the second or third Search Input lines, I retrieve multiple results.

Erica Rohlfs (erohlfs) on 2015-12-03
description: updated
Mike Rylander (mrylander) wrote :

Here's a branch to address this. From the commit message:

Before this change, the system would only check the first qtype URL parameter to see if it needed to apply the journal title "bib_level(s)" filter. Instead it should check each qtype in turn while it turns an advanced search into a simple search string. Here the code is moved into place to accomplish that.

To test, load all test datasets into a fresh database. Perform an advanced search on journal title for "proceedings" (no quotes) using the second search input row. Before this commit, two records are retrieved. After, only one is retrieved.


tags: added: opac pullrequest
Changed in evergreen:
milestone: none → 2.next
status: New → Confirmed
importance: Undecided → Medium
Kathy Lussier (klussier) on 2015-12-14
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) wrote :

The fix looks good Mike and works for me.

Since it does make a change to the perl code, I'm adding a needstest tag to this bug since we now have guidelines to include a regression test when a bug fix makes changes to perl or database code.

I have added a signoff to the current code and added it to the working repo at

tags: added: needstest
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
tags: added: signedoff
Mike Rylander (mrylander) wrote :

Kathy, because the perl in question is embedded in the large and complicated mod_perl environment, and the sub in question is called fairly deep down in the stack after a good deal of environment has been constructed, I don't think a test is feasible -- especially given the size (small) and clarity (high) of the change itself.

FWIW, the file syntax as a whole is already covered by the live tests, which is the extent of testing that any other mod_perl code gets.

More broadly, I think it's a mild oversight in our policy to say "perl code" when (at least as far as I can tell) we really mean "opensrf business logic code".

Kathy Lussier (klussier) on 2015-12-16
tags: removed: needstest
Kathy Lussier (klussier) wrote :

Thanks Mike! Merged to master, 2.9 and 2.8

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
milestone: 2.next → 2.10-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers