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

Bug #1659928 reported by Blake GH on 2017-01-27
This bug affects 2 people
Affects Status Importance Assigned to Milestone

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.................................

Blake GH (bmagic) wrote :

Here is what I got;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

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

tags: added: pullrequest
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
Blake GH (bmagic) wrote :


I updated the branch to reflect that suggestion.

Dan Pearl (dpearl) wrote :


Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
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.

Blake GH (bmagic) wrote :

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

Dan Pearl (dpearl) wrote :

Works for me. Thanks, Blake!

Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Galen Charlton (gmc) on 2017-08-10
tags: added: signedoff
Changed in evergreen:
milestone: none → 3.0-alpha
assignee: nobody → Galen Charlton (gmc)
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  Edit
Everyone can see this information.

Other bug subscribers