TPAC: eliminate advanced search filters from subsequent basic search box

[Kathy Lussier]

Evergreen version 2.2 RC1

A similar issue to the one fixed by https://bugs.launchpad.net/evergreen/+bug/986196. When limiting a search to a copy location group from the advanced search page, the location_group() filter remains in the search box, potentially causing problems if a user changes their search scope in their next search.

[Michael Peters (mrpeters)]

Tested and confirmed in master (2506f44).

[Thomas Berezansky (tsbere)]

I think this would be solved by this branch that puts all of the filters into a summary block below the basic search box:

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

I am also mentioning this branch on bug 1118377. I am not adding pullrequest because I don't know if it works with location_group at this time.

[Ben Shum (bshum)]

Combining with recently reported bug 1186048, which is similar. Forwarding content here:

In a tpac, go to advanced search
select, author/title/subject/series
do a search
in the drop down menu on the search results screen select one of the above options.
click the search button

the "title:" / "author:" / "subject:" / "series:" is not cleared from the search string before searching resulting in nesting values eg "title:title:Mushroom"

tested on 2.2 and 2.4

[Ben Shum (bshum)]

Confirmed that this is still affecting all versions of TPAC. Basically certain advanced search filters are making their way into basic search and if people aren't careful to clear terms, etc. they can get unexpected looking searches / results.

[Jim Keenan (jkeenan)]

Confirmed that this is still affecting all versions of TPAC as of Evergreen 2.8.4.

[Sally Fortin (sallyf)]

The developers at Equinox Software are working with MassLNC to resolve this bug. I've attached the tech specs for the fix.

[Galen Charlton (gmc)]

A branch is available as collab/gmcharlt/lp1005040_realign_search_layers in the working repository. This is not quite ready yet for a pullrequest, as it's pending customer feedback, but should be pretty close to the final version.

[Galen Charlton (gmc)]

Note that the branch has a dependency on OpenSRF bug 1631522; consequently, our proposed bugfix (which is veering towards a full-blown feature) will require OpenSRF 2.5.0.

[Mike Rylander (mrylander)]

I've updated the collab branch with three commits. Two are from bug 1281280 and help with a filter display issue on complex queries, and one is an enhancement to finalize the fix for that.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1005040_realign_search_layers

[Mike Rylander (mrylander)]

As a side effect of this branch, bug 1206593 is also fixed. The depth CGI param is retained. Marking that one as invalid and pointing to this from there...

[Jason Stephenson (jstephenson)]

So, I loaded this branch to see if it fixed bug 1662667. While it appears to fix that one, I see warnings like the following in osrfsys.log:

[2017-02-09 01:39:31] open-ils.search [WARN:8723:Application.pm:610:1486604282883011] open-ils.search.biblio.multiclass.staged: Use of uninitialized value in numeric gt (>) at /usr/local/share/perl/5.22.1/OpenSRF/AppSession.pm line 1071.

The above happens with a Z39.50 search for Mozart in the concerto database. I'm using OpenSRF master built on Dec. 9, so should be up to date with 2.5.0-alpha.

I know that these messages can often be ignored, but it is better if the code is fixed.

[Dan Scott (denials)]

Why was the following change made? (
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm;h=a5997067bb4bff03ff4ea3814938d9f4c8220738;hb=refs/heads/collab/gmcharlt/lp1005040_realign_search_layers#l1441)

     # Apostrophes break search and get indexed as spaces anyway
+ # XXX ^that's kinda a lie ..

If the comment that I authored almost eight years ago in the context of a fix for SlimPAC (6d3cdacfb) is no longer valid, then please either remove the original comment, or clarify it.

[Jason Stephenson (jstephenson)]

The branch on OpenSRF bug 1655449 fixed the warning message for me.

I pushed that to OpenSRF master, and I have no other concerns with this branch.

[Mike Rylander (mrylander)]

Dan,

The conversion to a tsvector does treat apostrophes the same way as spaces, in that they are word boundaries and are not included as a lexem. But they are stored in the value column of the relevant table and used for phrase matching. In fact, right now, phrase matching is broken in the slimpac (of little concern) and opensearch in general (of some concern) because of the code that I added the comment to.

I think the full fix is to remove the apostrophe stripping in opensearch. Not sure if this bug is the place to do that, but it's small and I'm happy to if there's consensus to get it in with this work.

Thoughts?

[Dan Scott (denials)]

Mike: so open a new bug about that specific (set of) issues, and remove the comment?

[Mike Rylander (mrylander)]

I've clarified the comment. Thanks!

[Kathy Lussier (klussier)]

Thank you Mike, Galen, Jason and Dan! Signed off and merged to master for inclusion in 2.12!