Comment 2 for bug 1887429

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.