Advanced Search - Clear Form doesn't clear location

Bug #1412218 reported by Terran McCanna on 2015-01-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

If you do a search filtered to an org unit, then go to the Advanced Search screen to do another search and hit the Clear Form button, it clears all the fields except for the previously selected org unit.

Preferred behavior would be to clear and revert it to the default org unit (ie, the user's preferred search location if logged in, the top level if not logged in and not in a library, the local library if accessing from within a library with a recognized IP address...)

Evergreen 2.7.2 & 2.5.1

Erica Rohlfs (erohlfs) on 2015-01-19
Changed in evergreen:
status: New → Confirmed
Adam Bowling (abowling) wrote :

Pushed fix to working.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=823d08655d6805258c6638e8faef640cc7d99c47

lp1412218_clear_advanced_search_ou:user/abowling/lp1412218_clear_advanced_search_ou

tags: added: pullrequest
Kathy Lussier (klussier) wrote :

Looking at https://bugs.launchpad.net/evergreen/+bug/994058, it appears as if the behavior to keep the search ou in place was by design. I was one of the people who asked that the "Clear Form" action not change the scope. I'm asking my team now what their opinions are on this. Is there any way we could make this behavior configurable?

Terran McCanna (tmccanna) wrote :

Reading through 994058, my interpretation of the concern was that it would reset it to the CONS level rather than the user's default preferred level. So the solution to that at the time was to just leave the scope at whatever it was when the user entered the page. This is fine if the user's default scope is BranchX and never changes it.

However, if the user changes it to BranchY to check to see if a neighboring branch has a book, then returns to the Advanced Search page and clears the form, I believe the user would expect it to return to the user's default BranchX (not CONS or BranchY), because it should be just like starting a brand new search.

Kathy Lussier (klussier) wrote :

Hi Terran,

I loaded this code on to one of our servers just to make sure I had a good handle on what it is doing. After looking at it, I would have to say it would not work well for at least one of our Evergreen sites.

It's always hard to say what a user's expectations will be. I think an argument can be made that many users might expect to search the same location during a given session, even as they change to entirely new search. However, there are other users that might choose to search one branch for one search, but expect to return to their default search library when conducing the next search. I think any system is going to get a mix of these users, and I would be hard pressed to say how the majority of users would be searching.

However, a consortium may set up a catalog in specific ways that would make this change problematic. As an example, you mentioned that the initial concern in bug 994058 was that it would reset the search to the consortium level. IIRC, that concern was voiced by Dan Scott. I don't want to speak for Dan (apparently I'm about to do so), but I know his catalog is configured so that when you go to https://laurentian.concat.ca/, the catalog is configued to automatically scope to his library's collections, adding a locg=105 to the URL. If this code is added to core Evergreen and a user who is not logged in uses his catalog, then it looks like we'll be back to the problem where the search library is being reset to the consortium, which isn't really the default for that catalog.

My concern is actually the opposite of what Dan voiced in that older discussion. We have an Evergreen site that, in its Apache config, adds locg=1 to the URL to automatically scope to the consortium. The reason is because a large percentage of their catalog searches are done from home where people are placing holds. That consortium doesn't want the default search to be the user's preferred librayr. Instead, the default search library is the consortium, and the preferred library is used as a means to float a user's library's holdings to the top of the list.

With this code, the user's search library would then be changed to their preferred library, even though the default typically is the consortium, not the preferred library.

We have other Evergreen sites that do not set the consortium as the default and may have different expectations of what should happen when the Clear button is used. This is why I was wondering if it's something that could be configurable, because I think the desired behavior here is closely tied to how an Evergreen site sets its default search.

Kathy Lussier (klussier) on 2015-12-09
tags: added: needsrepatch
removed: pullrequest
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers