action.hold_request_permit_test fail_parts can be confusing to end users

Bug #1481441 reported by Chris Sharp on 2015-08-04
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
2.10
Medium
Unassigned
2.8
Medium
Unassigned
2.9
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.rule_age_hold_protect.prox". However, the library in question owns two available and hold-eligible copies of the title. Upon further investigation, the patron is discovered to have fine in excess of the limit for placing holds. So the staff member is confused as to why the message is "config.rule_age_hold_protect.prox" when the reason should have been "PATRON_EXCEEDS_FINES". The action.hold_request_permit_test function apparently only passed up the last fail_part it found, which in this case is "config.rule_age_hold_protect.prox".

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

Jason Boyer (jboyer) wrote :

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.

tags: added: pullrequest
Jason Boyer (jboyer) wrote :

I should say that my branch doesn't fix this issue completely. It's still possible to get the transit message when placing the hold as a staff member at a location where no items may be sent (even when setting pickup location appropriately for the patron). I suspect this is related to bug 1167541, but haven't confirmed yet.

Changed in evergreen:
milestone: none → 2.next
Kathy Lussier (klussier) wrote :

We have a previous bug report on this issues posted by Jason Etheridge. I'll mark the other as a duplicate since this one has a working branch, but I also want to post a link to an IRC log discussion that ensued after Jason posted his bug.

http://irc.evergreen-ils.org/evergreen/2014-05-15#i_97605

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Jason Boyer (jboyer) wrote :

I have an alternative way to address this that I think would help, but is much more invasive (changes from the db tables up to the TPAC templates...) so I'll start a wishlist bug for it, and will link it here for further discussion by those interested.

Mike Rylander (mrylander) wrote :

Committed and backported (with some fuzz). Thanks, Jason!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
milestone: 2.next → 2.11-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers