The system preference 'maxoutstanding' is defined as the maximum amount
of fees owed by the patron before Koha should block placing holds (
terrible naming on this one ).
However, although the Koha OPAC respects this preference, placing holds
via a SIP2 device will not.
Test Plan:
1) Set maxoutstanding to $10
2) Pick a patron owning more than $10 in fees
3) Attempt to place a hold for this patron from a SIP2 device
This attempt should succeed
4) Apply this patch
5) Restart your SIP2 server
6) Attempt to place a hold for this patron from a SIP2 device again
This attempt should now fail
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Renewals were being rejected for incorrect reasons
Checking was being done against the wrong object
Add more informative messages on failure
Correctly set due_date for renewal response
Avoid crashing the SIPServer because it handles RenewAll
incorrectly
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
If a discharged item is captured for a hold at another branch
the selfcheck should generate a branchtransfer for it.
This was complicated as the checkin routine was setting its own
location from a field not set in many scm machines (e.g. 3M)
also in ILS::Transaction the test for location was incorrect
assuming that an empty string or undefined was a valid location
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Checking in an available item returns an error (which is correct) without
giving a reason for the failure as screen_msg (aka AF field in SIP2 is empty).
Based on code suggested by Patrick Langer <patrick.langer@easycheck.org>
Signed-off-by: Ulrich Kleiber <ulrich.kleiber@bsz-bw.de>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Allow fee paid to be supported for those machines which handle it
Development Sponsered by Halton Borough Council
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
If an invalid item barcode is passed to checkin
the sip2 connection dies. This is because although
no item object is created its mehods are called in Checkin
To maintain the connection properly catch the condition
and return the correct response to the unit
(should also fix Bug #3696 )
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Implement the optional fields: CR CS CT CV CY and DA.
Also silenced some outstanding debugging print statements.
Consolidated similar accesseor subs in Patron.pm to use x_items.
Adjust SIP tests to specify correct AP (location). Add a 3rd item
to SIPtext.pm for later use.
Note CT (destination) is currently populated with destination branch code.
We can adjust that to be destination branch name, or some combination in
a subsequent patch if necessary.
This work was sponsored by the Northeast Kansas Library system.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This includes some initial work for the 3M SIP2 extensions.
It also better populates the Patron object with methods for
a fuller Patron Information Reponse. This is positively affect
EnvisionWare software, as used by NEKLS.
This work was sponsored by the Northeast Kansas Library System.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The *_ok methods in ILS.pm were targeting the wrong depth.
This also resolves a longstanding FIXME on to_bool() warning like:
Argument "\x{66}\x{61}..." isn't numeric in numeric ne (!=) at /ILS.pm line 94.
The example_institution_dump.sh essentially provides the proof test case for this patch.
Run it before/after on SIPconfig.xml where "MAIN" has checkout="true" and checkin="true".
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This affects transactions on items that may be covered by
a title or item-level hold, but have not yet been retrieved
from the stacks (i.e. "confirmed") by the librarian. This does
not affect waiting holds (found="W"), so they will still block
transaction unless they belong to the operating patron.
Also I cleanup any hold the patron has on a biblio/item when
they are allowed to checkout the item.
Here we are filling the hold because the checkout is allowed, regardless
of of the queue position. This is different from AddIssue's CancelReserve, that
only fills the hold if it is next in line, but in the future AddIssue should
adopt a similar logic.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Allow valid comparison of hold_queue to current user barcode and
permit checkout if the current user is at the front of the queue.
Effectively, this allows a user to checkout a book he has held.
Here are the example checkout (11) and checkout response (12)
statements in a SIP telnet session, showing failure (120) previously
and success (121) after patch application.
Before:
11YN20060329 203000 AOCPL|AA1|AB502326000820|ACterm1
120NUN20081009 140222AOCPL|AA1|AB502326000820|AJKidnapped :|AH|AF2008-10-09 : Koha Admin (1)|BLY|
After:
11YN20060329 203000 AOCPL|AA1|AB502326000820|ACterm1
121NNY20081009 150204AOCPL|AA1|AB502326000820|AJKidnapped :|AH2008-10-10|AFItem was reserved for you.|
This patch also resolves security/privacy issues related to the display
of "needsconfirmation" values that identify, for example, the user
currently issued an item, or with a hold on the item. These messages
should not be passed to an end-user interface.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
