action.hold_request_permit_test fail_parts can be confusing to end users

[Chris Sharp]

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)]

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.

[Jason Boyer (jboyer)]

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.

[Kathy Lussier (klussier)]

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

[Jason Boyer (jboyer)]

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)]

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