Placing holds fails unintuitively when preferred pickup location is disabled via org unit setting opac.holds.org_unit_not_pickup_lib

Bug #1477154 reported by Michele Morgan
64
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
High
Unassigned

Bug Description

If a user has set a preferred pickup location, and that pickup location is disabled via the org unit setting opac.holds.org_unit_not_pickup_lib, the user can attempt to place a hold and their preferred pickup location is filled in automatically. Upon clicking "Submit", however, the form refreshes with no indication what the error is.

If the user opens the pickup location dropdown, their preferred pickup location is greyed out and cannot be chosen.

Here's a screencast:

http://screencast.com/t/I4YzNY5o

An error message stating that the patron's preferred pickup location is currently unavailable with instructions to choose another would eliminate confusion in this situation, and also avoid system behavior that appears broken.

Revision history for this message
Kathy Lussier (klussier) wrote :

Just adding a note that the same behavior occurs for org units that do not have the "can have users" flag enabled. If we provide a message for the situation that Michele described, we should see the same message for those org units that can't have users. I'm not sure how often my scenario would happen in practice, other than for the admin user, but I thought I would just throw it out there as another spot where we could use this message.

Revision history for this message
Dale Rigney (drigney) wrote :

The hold screen preferred pickup location is filled in automatically with the value of the opac.default_pickup_location user setting. If the patron does not have an opac.default_pickup_location user setting the preferred pickup location is filled in automatically with the patron's Home Library. If that home library has the opac.holds.org_unit_not_pickup_lib setting set to true the same silent failure happens.

Revision history for this message
Joan Kranich (jkranich) wrote :

Evergreen Release 3.2.10
Browsers Chrome and Firefox

Confirming that I can recreate the situations described by Michele and Dale, comment #2.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Jennifer Bruch (jbruchpails) wrote :

This has been coming up for PaILS/SPARK libraries as they close for COVID exposures and want to divert patrons elsewhere in a system.

Changed in evergreen:
importance: Undecided → High
tags: added: holds opac
Dan Briem (dbriem)
tags: added: circ-holds
removed: holds
Revision history for this message
Terran McCanna (tmccanna) wrote :

Note that this is still an issue in 3.6.1 Bootstrap OPAC

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

Still an issue through 3.8.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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