This reverts commit ca0e7541ec.
It was part of a patch set that removed actively used data and must be
therefore reverted.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a lookup of the sip user during an SC status, confirming that
our DB ocnnection is working, and that our user is still valid
Additionally, it adds support for SC status to the sip_cli_emulator and adds basic
test coverage for the SC status message
To test:
1 - Apply patch
2 - Restart SP server
3 - perl misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -m sc_status_request -su term1 -sp term1
4 - prove -v t/db_dependent/SIP/Message.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 14570 added a borrower_relationships table but it didn't remove the relationship column from the following tables:
- deletedborrowers
- borrowers
- borrower_modifications
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Loop is only interested in key values, because 'keys' is omitted
it is checking values as well. This can lead to misleading errors
being logged (e.g. key is undefined)
Extract keys only to loop array as in the other loops below this
Testing:
1 - tail /var/lib/koha/kohadev/sip-output.log
2 - in another tab use the sip cli tester:
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m checkin --item CHESS1
3 - Note errors:
Use of uninitialized value $key in index at /kohadevbox/koha/C4/SIP/Sip/MsgType.pm line 337, <STDIN> line 1.
Use of uninitialized value $key in index at /kohadevbox/koha/C4/SIP/Sip/MsgType.pm line 337, <STDIN> line 2.
4 - Apply patch and restart all the things
5 - Repeat 2
6 - Errors mentioned are gone
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 26673 renoved the shebang from SIPServer.pm. This was an error
SIPServer.pm is a program not a perl module, and needs the shebang
for the OS to assign an interpreter unless the command line
calls it as an argument to perl. Restore the shebang
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
PROCESSED gave the apearance that the item processing had been completed
whereas in reading the code it appears to actually signify that the item
is awaiting/in proessing state.
This patch updates the variable to be PROCESSING consistently throughout
the codebase.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This prevents checking out to a patron an item with hold to someone
else in the In Processing state via staff interface.
Also the checkout error message via SIP is now a more clearer one: "Item is
on hold for another patron." Before it was "Item cannot be issued:
$confirmation".
Also the branch transfer and batch checkout pages are adapted to this new
confirmation message as well.
To test:
1) Create bib level hold to an item for patron A
2) Check-in that item via SIP2, now the hold state should be "In processing"
3) Apply patch
4) Try to checkout the item to patron B via staff interface and
notice we get now confirmation prompt do we really want to do it
because it is in processing.
In order to not have to setup SIP2 server, alternatively steps 1) and
2) can be done so that you check-in the item in staff interface and
make it Waiting, and then with SQL change it to "In processing":
UPDATE reserves SET found = "P" WHERE reserve_id = XXX;
UPDATE reserves SET waitingdate = NULL WHERE reserve_id = XX
UPDATE reserves SET expirationdate = NULL WHERE reserve_id = XXX;
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Because AllowItemsOnHoldCheckoutSIP only affects the checkoutability
of non-attached, i.e. RESERVED holds in SIP2 we can therefore use the
common code from CanBookBeIssued and ignore only the RESERVED confirmation
message case in SIP2 checkout code.
This slightly changes the checkout error message given for "In
processing" holds that someone other than the holdee tries to
checkout. Otherwise there is no logic changes. The message that this
changes is "Item is on hold for another patron." vs. now "Item cannot
be issued: $confirmation". It is easier to create follow-up patch to
properly add INPROCESSING confirmation to CanBookBeIssued and then
show correct message based on the CanBookBeIssued return value.
To test:
1) Apply all patches from bug 25690 to get latest Transaction.t version
2) prove t/db_dependent/SIP/Transaction.t => passes
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Items that are attached to a hold and being transferred (found = T) is
final decision and you cannot checkout those to other patrons.
To test (if you have applied all patches from bug 25690):
1) prove t/db_dependent/SIP/Transaction.t => passes
To test (if you don't have all patches):
1) Create hold and set pickup library to something else where the
item is at
2) Return the item and it should confirm the hold and start transfer
3) Apply this patch
4) Try to checkout this item now to some other patron via SIP2 and
notice it doesn't allow it
5) Revert this patch
6) Notice you can now checkout somebody else's hold that is being transferred!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The patch "Bug 19116: Hold not set to waiting after transfer" added a
new meaning to 'Reserved' return value of C4::Reserves::CheckReserves
function. Let's remove double usage and have separate Transferred
return value so we can differentiate between attached and non-attached
holds. This will come useful in future refactorings.
This patch does no changes to the logic except in the
/cgi-bin/koha/circ/branchtransfers.pl and circulation.pl we now give
similarly to waiting state notice about hold being transferred.
To test:
1) Apply this patch
2) Create a new item level hold so that pickup library is different
than where the item is currently. Then return the item so that hold
is being attached and transferred.
3) Go to branchtransfers.pl and try to create a new transfer: it
should prompt you with message "Item is attached to a hold and
being transferred for XXX" and provide you with option to cancel
the hold or to ignore the transfer.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The SIP initiated transfer was set to use the 'TransferTrigger' passed
back from AddReturn; However, TransferTrigger is not set for reserves in
AddReturn (It's is set controller side by circ/returns.pl). We thus need
to also hard code the trigger type in the SIP transaction for reserves.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchs adds a new SIP option to block checkout of previously
checked-out documents: prevcheckout_block_checkout
See the CheckPrevCheckout system preference to enable previously
checked-out verification in Koha.
Test plan:
1) Apply this patch
2) Enable the CheckPrevCheckout syspref (on "Do" for instance)
3) Enable prevcheckout_block_checkout in the SIP server config file
4) Checkout and checkin an item for a user
5) Checkout the item again with the SIP CLI tool
6) Check that the SIP message is "This item was previously checked out by you"
and that the item was not checked out
7) Disable prevcheckout_block_checkout in the SIP server config file
8) Checkout the item again with the SIP CLI tool
9) Check that the SIP message is "This item was previously checked out by you"
and that the item was checked out.
10) Prove t/db_dependent/SIP/Message.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Caused by bug 23403 - when performing a checkin we lookup the SIP patron
using the borrowernumber, however, SIP only knows how to find a patron
via cardnumber or userid
The change on 23403 was to avoid using an 'id' that didn't always exist
(as some users don't have a userid or cardnumber
When checking in, however, we are not passed a user cardnumber or
borrowernumber, so we don't have those on hand to get the patron.
Test Plan:
1) Check in an item via SIP, note patron is not found
2) Apply this patch
3) Restart all the things!
4) Check in an item via SIP, patron should be found!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
SIP item stores the item unblessed so field must be accessed as a hashref
This patch changes the code in handle_item_information to match the code in
handle_checkin
To test:
1 - In sip config set the cr_item_field='itype' for a sip account
2 - Restart SIP
3 - Attempt an item information requests using the sip_cli_emulator
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m item_information --item 39999000011791
4 - It fails!
5 - Apply patch and restart
6 - It succeeds!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are two primary issues I've identified with requesting line items
for fees via SIP:
1) The end boundary is incorrect. For example, if send a request with a
BP ( starting item) of 1, and a BQ (end item) of 1, I should get just
the first item. Instead I will get two items
2) Our SIP server does not check bounds. For example, if I have 3 fines,
but I send a BP of 1 and a BQ of 5, I will get back 5 AVs, two of
them being "empty" because the patron only has 3 accountlines!
Test Plan:
1) Apply the unit test patch
2) prove t/db_dependent/SIP/Patron.t
3) Note the failures
4) Apply the second patch
5) prove t/db_dependent/SIP/Patron.t
6) All tests should pass!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If a renewal via SIP cannot be made because the patron has reached the maximum number of renewals,
the AF screen message should read "Item has reached maximum renewals!",
instead we get "Item checked out to another patron".
Test Plan:
1) Check out an item to a patron
2) Using the SIP CLI tool, run checkout messages until the checkout has
reached the maximum number of renewals
3) Note the incorrect message in the AF field
4) Apply this patch
5) Restart the SIP server
6) Run another SIP checkout message
7) Note the message is now correct!
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Those scripts are not known to be used, we can remove them from the Koha
codebase.
Test plan:
Confirm that the scripts removed by this patch are not used anywhere
from Koha.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In bug 21020 we used the issue to fetch the item and then the homebranch.
This fails when the item is not issued. We fetch the item already, so we
can use it directly
To test:
1 - Have an item belonging to branch A
2 - Check it in via sip at branch B:
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 --item CHESS1 -l FPL -m checkin
3 - The read command is blank and there is a warn about uninitialized data
4 - Apply patch
5 - Restart sip server
6 - Check the item in at branch A using the sip cli emulator
7 - Check it in at branch B
8 - This time the checkin should succeed and the output msg should be included
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This follow-up updates the config flag to be consistent with bug 24449
and updates the debian template file to match too.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 24449 implemented the too_many_overdue SIP flag ( position 6 of the
patron status flags ). This has had unintended consequences as
many library use SIP2 for validation to eresource vendors ( Overdrive,
Hoopla, etc ), but do not want overdue checkouts to block the
use of these resources.
Test Plan:
1) Apply this patch
2) Restart all the things!
3) Find a patron with overdue items
4) Run a SIP2 patron information request
5) Note the "too many overdue" flag is set
6) Set the new SIP config option "disable_too_many_overdue" for the
account you used for testing
7) Restart the SIP server
8) Run the same patron information request
9) Notice the "too many overdue" flag is no longer set!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds support for unseen renewals.
Here we retrofit knowledge of unseen renewals and add the display of unseen
renewal counts and warnings, in addition to adding the ability to
specify a renewal as being "unseen".
The functionality added here is goverened by the UnseenRenewals syspref.
Signed-off-by: Sally Healey <sally.Healey@cheshirewestandchester.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It appears that at some point, the actual blocking of checkins on items
with holds got lost from the patch set. This slipped by because the sip
server still outputs everything correctly, but the unit tests don't
actually test to see if the checkout still exists afterward!
Test plan:
1) Apply this patch
2) Prove t/db_dependent/SIP/Message.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Matthias Meusburger <matthias.meusburger@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It's not needed.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
JD amended patch, fix:
FAIL C4/RotatingCollections.pm
FAIL pod
*** WARNING: line containing nothing but whitespace in paragraph in file C4/RotatingCollections.pm
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This adds new syspref, HoldsNeedProcessingSIP, which controls whether
a hold that is related to item will be filled automatically or not. If
the user has enabled the syspref then instead of fulfilling the hold
automatically the hold will go to "in processing" state.
To test:
1. Checkout a book to patron A
2. Place a bib level hold to the book for B
3. Patron A returns the book via SIP, to simulate this use:
./misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --item <ItemBarcode> -m checkin
4. Notice that no notification is generated for Patron B about hold
and that the hold status in intranet and opac is "In Processing".
5. Notice that patron A (or other patrons) cannot checkout a book
that is in processing, because it is considered to be attached to
the holdee (similarly to the waiting state):
./misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --patron <PatronABarcode> --item <ItemBarcode> -m checkout
Signed-off-by: Timothy Alexis Vass <timothy_alexis.vass@ub.lu.se>
Rebased-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like to not only block the circulation of a guarantor based on fines owed by guarantees, but would also like to block circulation for all guarantees as well. Basically, if a family as a whole reaches a certain threshold of fines, the entire family will be blocked from checking out items.
Test Plan:
1) Apply this patch
2) Set NoIssuesChargeGuarantorsWithGuarantees to $14
3) Create a family of four ( 2 guarantors, 2 guarantees ) where the parents guarantee both children
4) Give 3 of the 4 a $5 fine
5) None of them should be able to check out items
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch capitalizes the 'ADDITIONAL_MATERIALS' key in the
needsconfirm hash return value for CanBookBeIssued to restore
consistency with previous code and ensure SIP Checkout works as
expected.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan
1/ Enable the feature as per previous patches
2/ Attempt to return an item with materials attached via a SIP unit
3/ Note that the return is blocked with an alert type of '99'
4/ Signoff
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan
1/ Enable the feature as per previous patches
2/ Attempt to checkout an item with materials attached via a SIP unit
3/ Note that the checkut is blocked with the message 'Item must be
issued at a circulation desk'
4/ Signoff
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries need to send a different field as the collection code,
depending on how the library catalogs items. We should allow any arbitrary
item field to be used as the value for the CR field.
Test Plan:
1) Apply this patch
2) Set the new option cr_item_field to 'shelving_location'
3) Restart the SIP server
3) Perform a checkin via SIP
4) Note the CR field contains the shelving location code in the response
5) Perform an item information request
6) Note the CR field contains the shelving location code in the response
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
.pm must not have -x
.t must have -x
.pl must have -x
Test plan:
Apply only the first patch, run the tests and confirm that the failures
make sense
Apply this patch and confirm that the test now returns green
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch defaults the 'holds_block_checkin' configuration to disabled
(to maintain current behaviour on upgrades). It also updates a
copy/paste for siplog logging to make the message triggered by this
action unique as expected.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like patrons to be unable to return items with
holds via SIP. Instead, the screen message should indicate that the
patron should return that item at the circ desk so a librarian can use
it to fill the next hold right away and place it on the hold shelf.
Test Plan:
1) Apply this patch.
2) Place a hold for an item.
3) Enable the new SIP option no_holds_checkin for a SIP account.
4) Restart the SIP server.
5) Check in the item using the SIP CLI tool using the SIP account
for which you set the new option.
6) Note the checkin fails with a screen message indicating you should
return the item to the circulation desk.
Signed-off-by: Peter Lau <peter.lau@yccece.edu.hk>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The 'summary' field in the patron information request specifies if detail information should be send for holds,
overdues, fines, etc. The field is 10 characters in length (0-9). However, the SIP2 spec only defines indexes 0
though 5, leave 6 though 9 undefined. Some ILSs specify behavior for these undefined indexes. Apparently the
7th field is often used to request 'Fees', as opposed to 'Fines' in some ILS. Some software that integrate via
SIP try both the 5th and 7th indexes to ensure they get all fines and fees.
The problem is that Koha's SIP server crashes if any 'summary' index beyond 5 is flagged. We should simply
ignore flags beyond 5 and act as if no flags were sent.
Test Plan:
1) Enable SIP for your instance
2) Send a patron information request with a summary flag in any index beyond 5.
i.e.: 6300120200617 124846 Y AOMIDAY|AA21030050054321
3) Note the SIP server just closes the connection without a response
4) Apply this patch
5) Restart the SIP server
6) Send the same request
7) Note you get back the patron information response!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jeff Gaines <jgaine@arlingtonva.us>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should support the SIP2 "circulation status" value 12, "lost".
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that we have return claims in Koha, we should support the SIP2
"circulation status" value 11, "claimed returned".
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should support the SIP2 "circulation status" value 10, "in transit
between library locations"
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some SIP devices need access to item fields that are not sent as item information in the checkin, checkout and item information responses.
It makes sense to allow these fields to be sent in an arbitrary and configurable way, rather than hard code in each special case.
Test Plan:
1) Apply this patch
2) Edit your SIP2 config file, add the following within the login stanza:
<item_field field="XX" code="<item field 1>" />
<item_field field="XZ" code="<item fied 2>" />
where <item field 1> and <item field 2> are item table columns of your choosing
3) Using the sip cli emulator, run checkout, checkin and item information
messages using that item.
4) Note the values you set for the item columns are sent in the
corrosponding fields!
Signed-off-by: Jill Kleven <jill.kleven@pueblolibrary.org>
Fixed merge conflict with number of tests (was 5, changed to 7 which is correct)
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the subroutines are not exportable we get the following crash:
> Undefined subroutine &C4::SIP::SIPServer::set_logger
To test:
In kohadevbox run for example:
$ ps -aux # check that no existing sip server is running, kill the process if exists
$ perl /kohadevbox/koha/C4/SIP/SIPServer.pm /etc/koha/sites/kohadev/SIPconfig.xml
$ koha/misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --item 3999900000001 -m item_information
After applying this patch the Undefined subroutine error should be gone.
Note: when using the sip_cli_emulator.pl the credentials can be anything.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This bug is basically the same as bug 24966, but for hold_patron_name instead of hold_patron_bcode.
The subroutine hold_patron_bcode should always return an empty string, not undef.
Test Plan:
1) Using the SIP cli emulator, checkin an item that is not checked out
2) Note the DA field contains someting like "C4::SIP::SIPServer=HASH(0x88175c8)"
The hex number will almost certainly be different from this example
3) Apply this patch
4) Restart the SIP server
5) Run the SIP checkin again
6) Note the DA field is no longer present!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
== Test plan ==
1 - Have two patrons with userids and no cardnumber
2 - Note which of these has the higher borrower number
3 - Use the SIP cli emulator to connect and checkout a book to the patron with higher borrowernumber
See example after
4 - Note the book may checkout to the wrong patron!
5 - Apply patch
6 - Checkout to both patrons via sip
7 - The patrons get the correct checkouts
=== SIP CLI emulator ===
./misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su term1 -sp term1 \
-l CPL --patron 23529001000463 -m checkout --item 39999000001259
translation: via the koha user term1, checkout item 39999000001259 to
patron 23529001000463
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* We should not call Log::Log4perl directly
* Not sure it is correct as I get from (comment 77):
% koha-sip --restart
[2020/04/23 11:23:27] [ERROR] [undef]@[undef]: Argument "0.33_01" isn't
numeric in numeric lt (<) at /usr/share/perl5/Net/Server/Log/Sys/Syslog.pm
line 42.
C4::SIP::Trapper::PRINT /kohadevbox/koha/C4/SIP/Trapper.pm (24)
Why "ERROR" when it's a warning?
The [undef]@[undef] seems wrong here.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
