Some SIP services ( such as Comprise ) require that an attempt at
over-paying a patron's account via SIP2 should fail, rather than create
a credit on the account. We should make this a configurable option on a
per-login basis in the SIP2 config file.
Test Plan:
1) Apply this patch
2) Enable the new parameter
disallow_overpayment="1"
for the login to be used in this test.
3) Restart your SIP server
4) Create or find a patron with fines
5) Attempt to send a payment via SIP for more than what the
patron's balance is
6) Note the response indicates a payment failure
7) Attempt to send a payment via SIP for the account balance or
less
8) Note the response indicates the payment has succeeded
9) Verify in Koha that the payment was processed
Signed-off-by: Rhonda Kuiper <kuiper@roundrocktexas.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As per bug 18966 AddReturn returns false with a DataCorrupted message
when the issue_id at hand already occurs in the old_issues table.
This should be handled when returning an item via SIP too. SIP should
not pretend that the checkin was successful, since this item needs
special care.
The following six different situations are handled:
[1] An attempt to checkin an invalid barcode is handled as before. The
ok flag is false; the screen message shows 'Invalid Item'.
[2] We receive a DataCorrupted message: the alert type is set to the
unused 98 code to indicate this new error condition. The ok flag
is false; the screen message shows 'Checkin failed: data problem'.
[3] The item checked in was not checked out AND the option checked_in_ok
is active. The ok flag is set to true; no screen message.
[4] The item checked in was not checked out AND the option checked_in_ok
is not active. The ok flag is not changed (normally false); the screen
message shows 'Item not checked out'.
[5] (The regular checkin) The item was checked out and AddReturn returned
true. The ok flag is true; no screen message.
[6] ("Otherwise") The item was checked out, but AddReturn returned false.
The ok flag is false; the screen message shows 'Checkin failed'.
Note: Currently this case only refers to the Wrongbranch and withdrawn
messages from AddReturn (where doreturn==0).
Note: Situation 1 and 5 are unchanged. Behavior is slightly changed for
situation 3 and 4; the option is only used when the item was not checked
out. Situation 2 and situation 6 are changed. After bug 18966 SIP
returned OK in case of data corruption (while checkin failed). In the
remaining cases under [6] SIP also returned OK while checkin failed.
Test plan:
[1] Test all six cases listed above. In order to simulate data corruption
insert the issue_id at hand in old_issues before you check in.
In cases 3 and 4 you need to toggle the option in your SIPconfig.xml and
restart the SIP server.
Case 6 can be tested by checking out at branch A, adjusting the value
of pref AllowReturnToBranch and checking in at branch B.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Many SIP2 services such as those by Comprise Technologies are able to or
require that an ILS be able to accept writeoffs via SIP2. The SIP2
protocol specifies that payment type be a two digit number, but does not
specify a code for writeoffs. To this end we should allow the write-off
code to be specified in the SIP2 config on a per-account basis so that
if different vendors use different fixed codes for write-offs we can
handle that gracefully.
Test Plan:
1) Apply this patch
2) Modify your SIP2 config to include
payment_type_writeoff="06"
in the login portion of the account you will be using for the test.
3) Restart your SIP2 server
4) Create a fee for a patron
5) Send a SIP2 fee paid message specifying the payment type code we
defined earlier, with a payment amount that is *not* equal to the
amount outstanding for the fee.
6) Note the fee paid response indicates the payment failed
7) Repeat step 5, but this time send the amount outstanding as the
payment amount
8) Note that the fee paid response indicates a successful payment
9) Note in Koha that the fee has been written off!
Signed-off-by: Rhonda Kuiper <kuiper@roundrocktexas.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The SIP protocol allows for a Fee Paid message to specify a fee
identifier in the CG field. While this field is read and passed to
C4::SIP::ILS::pay_fee, it is not passed along to
C4::SIP::ILS::Transaction::FeePayment::pay and is thus not used. We
should enable this functionality in Koha now that accountlines each have
a unique identifier that can be passed along to the payment requestor
via the AV field line items added by bug 14512.
Test Plan:
1) Create a fee in Koha
2) Ensure your SIP2 server is running and configured correctly
3) Send a 37 Fee Paid message to Koha's SIP server with the
accountlines_id for that fee in the CG fee identifier field,
along with the other required fields.
4) Note that specific fee was paid in Koha
Signed-off-by: Rhonda Kuiper <kuiper@roundrocktexas.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch specifically adds a test for the sub added to
resolve Bug 15479. As no test script existed to add this two
added one which also tests that ILS objects can be instantiated
correctly and offer the required interface
NOTE: This does not apply without the first patch.
Comment #3 suggested a unit test that would fail
before and pass after. So while this code is good,
it missed the before case. -- mtompset
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The borrowers table is defined COLLATE=utf8_unicode_ci which means
that cardnumbers may be saved in either lowercase or uppercase and
these are considered equivalent.
The server was performing a case sensitive comparison between
the incoming patron identifier and that retrieved from the db
As a result some renewals were rejected as being on loan to
another borrower if the stored cardnumber differed in case.
Make code comparison comply with db.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If an item is not checked out when a checkin via SIP2 is attempted,
Koha's SIP server sends back an "ok" of 0, and the AF message "Item
not checked out". I am not entirely sure this is good and correct
behavior by the SIP2 protocol.
In particular, this will cause SIP2 book sorting devices to fail on
all items that are not checked out, causing them all to be put into
the "special handling" been that should be reserved for things like
items checked in at the wrong library and items on hold.
Test Plan:
1) Apply the patch for bug 13159 so you can use the new enhanced
SIP2 command line emulator
2) Use a command similar to the following to check in an item:
sip_cli_emulator.pl -a localhost -su <sip user> -sp <sip password> -l <instituation id> --item <barcode> -m checkin
3) Note the 3rd character is 0, and there is an AF field saying the item is not checked out
4) Apply this patch
5) Restart the SIP server
6) Repeat steps 2-3, note that nothing has changed
7) In the SIP config file, Add the parameter checked_in_ok="1" to the SIP account you are using.
8) Restart the SIP server
9) Repeat steps 2-3, note that this time the 3rd character is 1, and you do not recieve the item not checked out message.
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Implement correct handling of fees associated with checking out
an item.
This is associated with fee acknowledged field (BO)
To quote from the Sip2 document
" If this field is N in a Checkout message and there is a fee
associated with checking out the item, the ACS should tell the
SC in the Checkout Response that there is a fee, and refuse to
check out the item. If the SC and the patron then interact and the
patron agrees to pay the fee, this field will be set to Y on a second
Checkout message, indicating to the ACS that the patron has acknowledged
the fee and checkout of the item should not be refused just
because there is a fee associated with the item"
So there are two Checkout requests the first with BO not set to Y is
rejected but the fee amount is returned. The Second Checkout with BO set
to Y should succeed.
Added a debug log message indicating why we block a checkout
when we dont otherwise indicate
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
For historical reasons the SIPServer and SIP modules
have used an extra module path in addition to the
standard Koha one. This has caused numerous irritants
in attempting to set up scripts and basic tests. It
does not help in attempting to modify or debug
this code
This patch changes the package value in the modules
under the C4/SIP directory and makes calls to
them use the full package name.
Where the export mechanism was being short circuited
routines have been explicitly exported and imported
declarations of 'use ILS' when that module was
not being used and which only generated warnings
have been removed.
As a lot of the changes affect lines where
an object is instantiated with new. The opportunity
has been taken to replace the ambiguous indirect
syntax with the preferred direct call
In intializing ILS the full path is added as this
will not require any changes to existing configs.
I suspect this feature is unused, and adds
obfuscation rather than flexibility but have kept
the feature as we need this change in order to
rationalize and extend the testing of the server.
The visible difference is that with the normal Koha
PERL5LIB setting. Compilation of Modules under C4/SIP
should be successful and not fail with unlocated modules,
allowing developers to see any perl warnings
All the SIP modules can now be run through the tests
in t/00-load.t now except for SIPServer itself
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Currently Koha's SIP server ignores the return date part of an 09 ( aka
CHECKIN ) message. Koha should backdate a return, and remove
fines accordingly.
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Works as notified, second date field in SIP checkin (return date) is
used as return date. Return shows up in history with correct date.
Comments:
- patron is fined if return date is before issue date, but that
is largely irrelevant anyway.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds support for recording in Koha accountlines a different accounttype
depending on how the fee was paid at the SIP2 station (cash, credit,
etc.)
Adds a new param to recordpayment(), $sip_paytype, which is appended to
the 'Pay' type if present. The payment description is also appended
with " (via SIP2)" if this is present.
In order for other scripts to keep working as expected, "eq 'Pay'"
needed to be replaced with a regex comparison "=~ /^Pay/", so that 'Pay'
and 'Pay-##' would continue to group together.
To test:
1. Make a payment over a SIP2 connection
2. Check the patron record in the staff client; you should see the
modified description
3. Attempt to print a invoice or a reciept for the borrower; the
payment should show up where expected
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
