SIP is not respecting standing penalties for charge ok and hold ok

Bug #1659928 reported by Blake GH
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned

Bug Description

This might be related to LP1534283

SIP currently allows a user to circulate with standing penalties that specifically block CIRC.
SIP currently allows a user to place holds with standing penalties that specifically block HOLD.

When handling a Patron Info (63) message, one of the values consulted is the SIP patron object's hold_ok value, which is currently just a copy of their charge_ok value.

charge_ok and hold_ok need to take a look at the specific penalties and the actions that those penalties block.

6300120170112 060147 AO|AA{patron barcode that has a penalty with block list CIRC}|AC|ADelsey|BP1|BQ1
results in
64 Y 00020170127.................................

it should be
64Y Y 00020170127.................................

Revision history for this message
Blake GH (bmagic) wrote :

Here is what I got

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/LP1659928_SIP_is_not_respecting_standing_penalties_for_charge_ok_and_hold_ok

I originally wrote the section on renewing for LP1534283
https://bugs.launchpad.net/evergreen/+bug/1534283

This patch rewrites that and charge_ok and hold_ok to be consistent.

tags: added: pullrequest
Revision history for this message
Galen Charlton (gmc) wrote :

The patch reads OK to me, but one thing jumps out. Expressions like

  $_->block_list =~ /CIRC/

don't account for the possibility that the block_list value could be NULL (or undef as it would get represented in Perl code), and "undef =~ /foo/" will produce a warning. I suggest trying something like this:

  ($_->block_list // '') =~ /CIRC/

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Blake GH (bmagic) wrote :

Galen,

I updated the branch to reflect that suggestion.

Revision history for this message
Dan Pearl (dpearl) wrote :

Testing

Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Revision history for this message
Dan Pearl (dpearl) wrote :

I think the examples in the original problem statement were munged by launchpad. Multiple spaces were compressed down to single spaces, so the 14-character patron status fields were compressed in an unexpected manner.

Revision history for this message
Blake GH (bmagic) wrote :

That's entirely possible.
The return message should look like:
64YYYY<10 chars>00020170809<4c>........

Revision history for this message
Dan Pearl (dpearl) wrote :

Works for me. Thanks, Blake!

Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Revision history for this message
Dan Pearl (dpearl) wrote :
Galen Charlton (gmc)
tags: added: signedoff
Changed in evergreen:
milestone: none → 3.0-alpha
assignee: nobody → Galen Charlton (gmc)
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master. Thanks, Blake and Dan!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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