action.hold_request_permit_test fail_parts can be confusing to end users
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.10 |
Fix Released
|
Medium
|
Unassigned | ||
2.8 |
Won't Fix
|
Medium
|
Unassigned | ||
2.9 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Found at a PINES library: A staff member attempts to place a hold for a patron on a newly-released title via the staff client OPAC view, and the reason presented for not being able to place the hold is the text for "config.
I'm honestly not sure what a good approach is here, but I think this is a bug that can confuse staff and patron end-users.
Evergreen 2.7.2+
OpenSRF 2.4
PostgreSQL 9.3
Ubuntu LTS
Changed in evergreen: | |
milestone: | 2.next → 2.11-beta |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
As it happens, changing the order of the reasons in place_hold_ result. tt2 will make the more relevant messages float to the top. Here's a branch that EI is currently using: http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/collab/ jboyer/ lp1481441_ hold_fail_ reason
Now, when a hold is denied because of patron fines or other penalties, that reason will be shown, in my testing I only saw the transit message when it was the only reason for the failure.