Ang staff catalog sometimes fails reading hold pickup lib pref

[Bill Erickson]

Evergreen 3.4 / 3.5

Numeric user (and org unit) settings may be stored as JSON numbers or JSON strings in the EG database. When the user setting 'opac.default_pickup_location' is stored as a string, the angular staff catalog fails to make proper use of the value. When this happens, the hold form fails to display the patron's name and does not allow the holds to be placed.

To test:

* Apply a string value for an instance of the 'opac.default_pickup_location' user setting for a test user account (E.g. via SQL: UPDATE ... SET value = '"4"').
* Perform a catalog search
* Select Place Hold
* Click Search for Patron
* Find the modified patron in the search form and double-click the row to select
* Note how the form fails to fully render (and there will be console errors).

Patch coming.

[Bill Erickson (berick)]

Fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1887429-staffcat-def-hold-pu-lib-string

[Michele Morgan (mmorgan)]

I tested using Bill's steps to reproduce the problem on an unpatched system running 3.5. Though I did not see the broken screen he describes, I did observe that the patron's pickup preference was not read. Instead, the hold pickup location matched the staff workstation.

Testing on a patched master system, and a patron with opac.default_pickup_location set to "6", the user setting is properly read using the following steps:

* Perform a catalog search
* Select Place Hold
* Click Search for Patron
* Find the patron in the search form and double-click the row to select
* Pickup location is filled in based on the user's preference
* Hold is successfully placed.

So the patch looks to fix the workflow where a patron search is performed on the Place Hold screen.

However, I am seeing 2 workflows where the patron's preferred pickup location is not being read properly:

1.

* Perform a catalog search
* Select Place Hold
* Enter the patron's barcode in the 'Place hold for patron by barcode' field and click Submit
* Pickup location does NOT reflect the user's preference

2.

* Retrieve a patron and navigate to Holds
* Select Place Hold
* Perform a catalog search
* Select Place Hold
* Pickup location does NOT reflect the user's preference

Note that workflows 1 and 2 above both fail to read the user's preference for opac.default_pickup_location values of 6 or "6", so this is not a JSON number vs. JSON string issue.

[Bill Erickson (berick)]

Thanks, Michele. Issues confirmed.

[Bill Erickson (berick)]

Here's a new branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1887429-staffcat-def-hold-pu-lib-string-v2

This is a rebaesed, squashed version of the the previous branch, including fixes for the 2 issues Michele noted.

[Michele Morgan (mmorgan)]

I need to amend my previous comment based on further testing.

When a patron has a default pickup location preference, Bill's patch properly reads the patron's pickup preference for his stated Place Hold workflow. For other Place Hold workflows, the patron's preference is not read, the pickup location is set to the staff workstation.

Also, this behavior differs from the current catalog for staff placed holds.

Current catalog behavior for staff placed holds:

If the patron does not have a default pickup location preference, the pickup location should be set to the patron's home library.

If the patron does not have a default pickup location preference AND the ou setting circ.staff_placed_holds_fallback_to_ws_ou is set to TRUE, the pickup location should be set to the staff workstation.

The angular catalog with (or without) Bill's patch applied does not consult the ou setting, and different workflows result in different derivation of pickup location for a patron with no preference set.

I've attached a text file with a testing plan and results.

Removing pullrequest and adding needsrepatch.

Because this will cause a great deal of confusion for staff placed holds, I'm also adding a

[Bill Erickson (berick)]

The plot thickens! Thanks, Michele. Looking at these...

[Bill Erickson (berick)]

For reference:

https://bugs.launchpad.net/evergreen/+bug/1889128/comments/9