Web Client: Clear Form on Patron Search displays 'Home Library'

Bug #1721131 reported by Terran McCanna
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

On 3.0:

If I open the patron search screen, the org unit box is set to the consortium level (CONS with test data, PINES with our data). However, if I click the Clear Form button, it resets the dropdown to "Home Library."

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

I can confirm this bug as well. Also, once the org unit is set to "Home Library" the search returns no results.

Revision history for this message
John Amundson (jamundson) wrote :

In 3.2.1, at least, performing a search with org unit set to "Home Library", the search only returns patrons with the home library of my workstation's.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hello, EG 3.3.4 - Just noticed something similar, but may not be exactly the same.

1. Open up patron search, Home Library filter set to consortium.

2. Press the Clear Form button, which clears the Home Library filter, so it just shows the label.

3. Put in a name and search. Results in a search that isn't scoped to any home library.

4. Open up patron record.

5. Click on "Patron Search" in upper right corner to re-open search form.

6. Form is shown with the Home Library filter set to workstation org unit now.

This has resulted in staff not being able to find customers records, since we have patrons that use different libraries from their home library.

What should happen? Should the clear form button reset the home library filter back to consortium?

It looks like there is code to try and set the home_ou back to what was set for the last search, and when that is undefined, it gets set to the workstation ou.. but I cannot spot where that happens.

Josh

Revision history for this message
Terran McCanna (tmccanna) wrote :

For PINES libraries, we want Clear Form to always re-set to the consortium level. *Almost* every patron search that our staff does should be scoped to consortium level.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

It took me way too long to realize that an input type="reset" button resets all form controls after the clearForm() function is run. Have to change that to a regular button.

So another issue is that the home library is sticky, tied to eg.circ.patron.search.ou. That value is only set when the dropdown is clicked on and a new value is selected. Resetting the form doesn't change the sticky setting. So if you reset, search, open a record and then go back to the patron search form, the sticky setting comes back up. I can see that tripping up someone. And I see now that sticky settings like this are stored locally only, so there is no way to set a default on the server with org unit settings.

The home library control gets it's initial value from these sources in order.
1. Old search args from a previous search if they exist.
2. local sticky setting eg.circ.patron.search.ou
3. searchArgs.home_ou - which is set to consortium by default on initial load.
4. workstation ou

So the reason I was seeing the Home Library control get set to my workstation ou, is because there was no sticky setting and the form reset left the home_ou undefined, so the workstation ou was used.

I'm also wondering if the Include Inactive should always be set on a reset, to set the form to give the broadest possible search results when reset?

Here is a working branch that does the following.
1. Change the Clear Form button so it isn't a reset button, all resetting is handled by clearForm().
2. Set the home library to cons on reset.
3. Set include inactive to true on reset.

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

Then locally, we will define an org unit settings to set defaults for eg.circ.patron.search.include_inactive to set defaults to true, and delete the workstation setting type so someone will always need to make a deliberate decision to uncheck that box.

I cannot see a way to set a default for eg.circ.patron.search.ou since it is a local browser setting. So maybe clear form should also reset that local setting? Otherwise I can see that tripping someone up. Maybe Home Lib should not be set as sticky, and patron_search.js should handle setting a workstation/user setting that can be better controlled through existing methods?

It would be good to hear from a location that does want searches limited by Home Lib for all searches.

Josh

tags: added: pullrequest
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Thanks for the pull request, Josh! It definitely works as advertised; whenever I click on "Clear Form", the org selector goes to CONS.

We're usually searching at a system level. So it would be much more helpful if the Clear button just remained on the most recent sticky setting. Switching to the root org on "Clear Form" seems unintuitive to us.

Persisting the selected OU through clearing the form would make more sense to me.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I agree with Jane regarding the Home Library org unit selector. Reverting the selector to the sticky setting when using the Clear Form button makes logical sense.

I do have a lingering concern that this could result in some patron searches getting limited unintentionally. This issue could be addressed in training, but another possibility would be an additional button "Search All Libraries" that would rescope to the Consortium and perform the search. I'm not exactly sure where that button might go on the screen. Also that might be crossing over into wishlist territory rather than bug fix.

One element of Josh's fix that I would vote to change is the handling of the "Include Inactive" checkbox. I would prefer not to always check that box when the Clear Form button is clicked. It's rare that staff in our libraries would search for patron records that are inactive. I would vote that the "Include Inactive" should revert to the sticky setting as well.

Revision history for this message
Terran McCanna (tmccanna) wrote :

I'm okay with the Include Inactive box being sticky, but FWIW, our libraries are supposed to always search inactive patrons because it's one of the main ways we run across duplicate accounts. Unchecking the box should be a rarity for us.

Revision history for this message
John Amundson (jamundson) wrote :

Maybe I am misunderstanding something here, but if we make the decision to revert back to the most recent sticky settings, doesn't that completely defeat the purpose of the "Clear Form" button?

As a test, (the patch isn't needed for this test)...

1. Open up Patron Search and set Search OU to CONS.
2. In a new tab, go to Workstation>Stored Preferences>In-Browser Prefs.
3. Find "eg.circ.patron.search.ou" and confirm the value is set to '1' (or whatever org you selected above).
4. Return to the Patron Search tab. Set Search OU to another option, (i.e. BR1). You don't even need to perform a search. Just choose a branch from the dropdown.
5. Return to the Preferences tab. Refresh the page. Return to "eg.circ.patron.search.ou". Confirm the value is set to the new org unit ID.

A similar process can be done for "eg.circ.patron.search.include_inactive", which lives under Server Workstation Prefs on my system.

If the "Clear Form" button reverted to the sticky search_ou session, then nothing would change, correct? Because the setting is already set to whatever branch you just filtered on?

I would be in favor of the "Clear Form" button reverting search to the broadest terms possible - CONS and include inactive, (or perhaps retaining the sticky setting for inactive).

In my testing on both Evergreen 3.2.10ish and 3.5ish, if you refresh the page, the search form reverts all manually entered terms as well as Profile Group. If staff want to keep their sticky OU and inactive settings, they could simply refresh the page to achieve it.

The only time I personally feel a need to use the "Clear Form" button is when I need to clear fields that are not cleared on a refresh.

tags: added: needsdiscussion
Changed in evergreen:
milestone: none → 3.6.1
Changed in evergreen:
milestone: 3.6.1 → 3.6.2
Revision history for this message
Terran McCanna (tmccanna) wrote :

Removing pullrequest as there is some disagreement about what Clear Form should actually do

tags: removed: pullrequest
Changed in evergreen:
milestone: 3.6.2 → 3.6.3
Changed in evergreen:
milestone: 3.6.3 → none
tags: removed: webstaffclient
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hello John, I think I agree with you.

"I would be in favor of the "Clear Form" button reverting search to the broadest terms possible - CONS and include inactive, (or perhaps retaining the sticky setting for inactive)."

All our problems are from un-intentionally limiting searches, and then getting no results. To many results has never been a problem. And the home library selector being set and stuck (stickied) has been part of our problem.

We are going to go live with this patch as is. It improves on the current behavior and addresses the original issue.

Josh

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

"I would be in favor of the "Clear Form" button reverting search to the broadest terms possible - CONS and include inactive, (or perhaps retaining the sticky setting for inactive)."

I agree with this as well. We tell our libraries that their default patron search should always be the consortium with include inactive checked so that they see any duplicates.

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

To add to this, in 3.7 and 3.8 the patron search form via Place Hold has different behaviour when the Clear Form button is used than the Patron Search via the Search menu.

When you click "Search for Patron" on the Place Holds screen in the new staff catalogue, the patron search pops up. If you enter in terms and then click Clear Form, the form is cleared but the org unit field is not touched. It stays at whatever was last entered for that field.

The behaviour of the Clear Form button for Patron Search should be consistent across both these interfaces.

Revision history for this message
Blake GH (bmagic) wrote :
Revision history for this message
Dawn Dale (ddale) wrote :

This is still an issue in 3.8.0. Using the clear form button resets the library to "Home Library" and unchecks the "include inactive" box.

I believe the consensus is to have the library to reset to the highest level and the include inactive box to be sticky whether checked or unchecked. Also, to have the patron search screen in patron holds to react the same.

Revision history for this message
Shannon Dineen (sdineen) wrote :

This is still an issue in 3.9.0. Using the clear form button on Patron Search resets the library field to the org tree node Home Library and unchecks the include inactive tick box.

On the "Search for Patron" on the Place Holds screen in the staff catalogue, if you enter in terms and then click Clear Form, the form is cleared but the org unit field is not touched. It stays at whatever was last entered for that field. However, the previously checked include inactive check box is unchecked.

Revision history for this message
Blake GH (bmagic) wrote :

It seems that the needsdiscussion tag was added, and then we had a discussion. Is there an agreement that the last branch is the* branch? Ready for pullrequest?

Revision history for this message
John Amundson (jamundson) wrote :

I think the consensus is as Dawn states in comment #15

"I believe the consensus is to have the library to reset to the highest level [CONS] and the include inactive box to be sticky whether checked or unchecked. Also, to have the patron search screen in patron holds to react the same."

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.