"Where" filter in Bootstrap Catalog Produces Unwanted Results

[John Amundson]

Evergreen 3.7.2ish

We recently upgraded to Evergreen 3.7.2 with the Bootstrap public catalog.

In our network, many of our libraries utilize Shelving Location Groups to create "Children's Catalogs". In the Bootstrap catalog, these can be searched using the "Where" filter on the Advanced Search tab.

We are seeing two issues with the "Where" filter.

1. The options display in an arbitrary order. The order does not seem to be based on anything as reloading the page rearranges the order of the display. They should be displayed in alphabetical order.

2. If an option is chosen from the "Where" filter, it seems to be interacting oddly with the "Search Library" filter. I cannot tell if the "Where" choice is being ignored completely or if it's essentially performing an "OR" search where results are either in the Search Library or Location Group. In either case, the search should be "AND" - Only bring back items that are in the Search Library AND chosen location group.

For now, the only way to accurately use location groups is through the "Library" dropdown on the Basic Search tab.

[Benjamin Kalish (bkalish)]

This a big deal at our library. We very much look forward to a fix!

[Benjamin Kalish (bkalish)]

I wonder if this is a duplicate of https://bugs.launchpad.net/evergreen/+bug/1929072 ?

[John Amundson (jamundson)]

Noting that I do not believe that these bugs are duplicates.

This bug relates to the Where filter present in the Bootstrap catalog

When reading through comments on Bug #1929072, that actually seems to be an issue with empty bibs showing up in scoped searches.

[Christine Morgan (cmorgan-z)]

Marking this Confirmed based on the comments.

[Garry Collum (gcollum)]

We are a single system. All of our location groups are at the consortial level, so alphabetizing isn't difficult.

I set up some groups in the concerto database at different OU levels and they all appear in the menu, unsorted, without any indication of OU assignment.

Should the OU be listed next to the location group in the drop-down, or should the OU be listed in the drop-down with its assigned location groups underneath the OU name with the consortial OUs at the top of the list? Other options?

[Michele Morgan (mmorgan)]

Setting Importance to High as this has the bootstrap-blocker tag.

[Terran McCanna (tmccanna)]

The main cause of this problem seems to be that the options chosen in the library selector and the where (scope) selector may conflict with each other. On the basic search page, a single dropdown is used that combines the options of both lists, so only one can be selected and conflicts will be avoided.

So, my proposed patch here combines the two just as they are on the main page:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1970476_boopac_adv_search_where_problems

(Note that this will also be an improvement for libraries like mine that do not use library groups or shelving location groups because the "Where" selector on the Advanced Search page is unnecessary and confusing.)

This change is currently loaded onto a master test server with Concerto data at https://terran-master.gapines.org if anyone would like to test it there.

[Michele Morgan (mmorgan)]

Adding my signoff to this. This resolves the order of options and the conflicting nature of the two dropdowns. Having the same familiar dropdown is basic and advanced search is a plus also.

Here's my signoff branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1970476_boopac_adv_search_where_problems-signoff

user/mmorgan/lp1970476_boopac_adv_search_where_problems-signoff

I'd be in favor of backporting this to get it into the next point releases.

[Jason Stephenson (jstephenson)]

I don't know if Galen is still looking at this, but CWMARS is going to install this patch on a test server.

At first glance the patch contains some unnecessary chagnes that remove the l() translation wrapper from some text in the OPAC display. I'm going to put that back.

[Jason Stephenson (jstephenson)]

I put the missing localization function wrapper back in place and pushed a signoff branch to user/dyrcona/lp1970476_boopac_adv_search_where_problems-signoff. It adds a commit to restore the wrapper and includes John Amundson's signoff as well as my own on both commits.--Thanks for testing, John!

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1970476_boopac_adv_search_where_problems-signoff

I'm not pushing directly to master because I'm unsure if Galen is still looking at this or if commit from bug 1990306 went in already or not.

[Terran McCanna (tmccanna)]

Oops, I'm not sure how I removed the localization in my commit - sorry and thanks for catching it!

[Michele Morgan (mmorgan)]

+1 to pushing this to master!

[Galen Charlton (gmc)]

I've reviewed this and note that when library groups were introduced that the separate scope selector on the advanced search page was intentional:

https://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ddce92adc9

However, the commit that added Bootstrap OPAC support did not set the name of the scope selector correctly, so it currently does nothing.

Here's an example of how to restore some the functionality of the scope selector:

https://gist.github.com/gmcharlt/d70805a6283294d013c3569f5205a15d

This works in the sense that choosing a depth, a library group, or a location group from that selector applies the selected limit, but there remain rough edges. For example, if you navigate back to the advanced search page, your chosen search scope does not remain selected.

I'm neutral on the question of whether to fully resurrect the split location + scope selectors for the advanced search for or just have both basic and advanced search use the unified selector, but I want to explicitly raise the question for final discussion before pushing anything.

[Jason Stephenson (jstephenson)]

Your explanation makes sense, Galen. I'll defer to consensus on this as I don't have much to say about it either way. If the previous functionality was actually useful, then it would make sense to restore it. I don't know if it was or wasn't, so that is not intended as a value judgment on the behavior prior to Bootstrap OPAC.

[John Amundson (jamundson)]

At least as far as CW MARS purposes are concerned, the combined selector would work just fine for us, and staff/patrons are used to it.

[Garry Collum (gcollum)]

I agree with John the combined selector worked well, and our patrons and staff are used to it.

[Galen Charlton (gmc)]

I've pushed this down to rel_3_9. Thanks, Terran, Michele, John, and Jason!

There are of course remnants of the separate scope selector that could be revived in the future, perhaps, for a "super-advanced" mode, but that's a discussion for a different time, place, and possibly alternative universe where library patrons embraced DIALOG-style searching without reservation.