Koha has been able to send arbitrary item fields via the "item_field" parameter in the config. We have partners that need the ability to created custom item fields from templates, as the item_fields feature cannot accomplish what they need. We need to add a templated custom field feature for items, similar to what we have for patrons.
Test Plan:
1) Apply this patch
2) Choose a SIP login to use, edit that account and add the following
*inside* the login section:
<custom_item_field field="IN" template="[% item.itemnumber %]" />
3) Restart SIP
4) Run an item information query
5) Note the itemnumber is sent in the IN field!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: fixed tests count
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan ( assuming Koha Testing Docker or kohadevbox ):
1) Check out master
2) Start the SIP server ( edit the SIP config koha instutution to be
"CPL" instead of "kohalibrary" )
3) Telnet to 6001
4) Send 9300CNkoha|COkoha|CPCPL|
5) Send 11YY20220711 16350220250711 163502AOCPL|AA23529000035676|AB39999000001396|ACkoha|BON|BIN|
6) Note the due date for the checkout in Koha is not in the year 2025:
Henry Acevedo (23529000035676) checked out Philippics. by Cicero, Marcus Tullius. 39999000001396
7) Apply this patch set
8) Restart all the things!
9) Check in the checkout
10) Repeat steps 3 through 5
11) Note the due date is now in 2025!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We must not pass $dbh but retrieve it when needed instead
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some libraries have certain item types that can only do in house checkouts via SIP self check machines. In these cases, the items should not be demagnetized since the items cannot leave the library.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Message.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When placing holds via SIP2, there is no holdability check. This seems very incorrect.
Test Plan:
1) Apply this patch
2) prove -r t/db_dependent/SIP
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates SIP patron code to use account methods to calculate balances
over the patronflags returns. It also checks if patron should be blocked for each
'No Issues charge' preference
Tests are added for NoIssuesChargeGuarantees
To test:
1 - Set noissuescharge preference to 5
2 - Add a $10 charge to a patron
3 - perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m patron_information --patron BARCODE
4 - Note the 64 message starts with Y's that mean patron is blocked
5 - Set noissuescharge to 11
6 - Repeat 3, patron is no longer blocked
7 - Set NoIssuesChargeGuarantees to 8
8 - Repeat 3, patron is blocked
9 - Pay $3 on patron so they owe 7
10 - Repeat 3, patron is not blocked
11 - Add a child account with patron as guarantor
12 - Repeat 3, patron is not blocked
13 - Add a $4 charge to child
14 - Repeat 3, patron is blocked
15 - Repeat 3, but with child barcode, child is not blocked
16 - Set NoIssuesChargeGuarantorsWithGuarantees to 10
17 - Repeat 3, patron is blocked
18 - Repeat 3 with child barcode, child is blocked
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new option to the SIP config, allowing for hold
capture to be disabled on difference devices. We still notice the hold
and alert the user, but we do not trigger the update in the system to
mark the hold as found (waiting, processing or in transit).
Sponsored-by: Cheshire Libraries Shared Services
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Currently, on SIP checkout, Koha only returns "Patron Blocked" when there is
a problem with the patron.
This patch adds more specific informations, with the following messages:
- "Patron expired"
- "Patron debarred"
- "Patron has fines" (see system preference "noissuescharge")
- "Patron blocked" (see system preference "OverduesBlockCirc")
Test plan:
- Try to do a SIP checkout with a patron that is in one of the above situations.
- Check that the displayed message matches the patron's situation.
Signed-off-by: Sonia <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
In koha interface, a warning is displayed when an item on hold is returned
only if the return is for this specific item.
This patch does the same in SIP: the return is blocked when holds_block_checkin
is enabled and there is a hold on a specific item and this is the very item
being returned.
Test plan:
The following behavior is expected in SIP:
- An item is returned, and there is a reservation on record-level: block
- An item is returned, and there is a reservation on this very item: block
- An item is returned, and there is a reservation on another item: allow
Signed-off-by: Sonia <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
I added explanatory text to staff interface on the preference to explain how it works
Removed a debug warn in the _get_sort_bin routine
changed comparitor => comparator
fixed a missing call in the tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds support for specifying the comparison operator used in
the sort bin method. It allows for more complex cases where one may wish
to sort on groups of callnumbers for example.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This bug adds the SIP2SortBinMapping to make it possible to tell
the Koha SIP2 server to include a sort_bin/CL field in the
Checkin Response, if appropriate.
To test:
- Check out an item and return it via SIP2:
$ telnet localhost 8023
9300CNterm1|COterm1|CPCPL|
09N20200422 12430020200422 124300APCPL|AOCPL|AB001|AC|
(Where 001 in |AB001| is the barcode of the item in question)
- Check there is no CL field in the last response
- Apply the patch, fill in SIP2SortBinMapping with e.g.:
CPL:itype:BK:3
- Repeat the first step
- Check the respons contains a CL field with a value of 3 (or what
you put in the config). The field should look like |CL3|
- Signe ye offe
2020-06-25: Pass an item to _get_sort_bin, not a checkout. Rebase.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch refactors the pay method in SIP FeePayment such that we
consistently pass parameters to both invocations of Koha::Account->pay.
It ensure the missing cash_register definition is passed when a set of
account lines to pay is defined.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch removes the unused method.
Likely a leftover from ancient ages. AddIssue already fills the hold and
is called in the Checkout.pm library.
To test:
1. Run:
$ git grep fill_reserve
=> FAIL: Notice it is only mentioned in the line that defines it
2. Apply this patch
3. Repeat 1
=> SUCCESS: Removed.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch removes the flag to fetch the patrons own debts as we have already
calculated them
This test plan highlights another issue - the value of NoIssuesChargeGuarantorsWithGuarantees
is not checked in SIP code - we merely get the total owed including guarantees and compares to
noissuescharge
See bug 29755
To test:
1 - Apply first patch only
2 - prove t/db_dependent/SIP/Patron.t
3 - It fails
4 - Enable NoIssuesChargeGuarantorsWithGuarantees, you can set to 1
5 - Create/find a patron
6 - Add a $10 charge to parons account
7 - Add a guarantee to patron
8 - Add a $5 charge to guarantee
9 - Set noissuescharge to 15.01
10 - perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m patron_information --patron BARCODE
11 - Note the 64 message starts with Y's that mean patron is blocked
12 - Patron shouldn't be blocked as under 15.01
13 - Apply patch
14 - Restart all
15 - repeat 10
16 - Patron is no longer blocked
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
It has been missed on bug 17600.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adjusted commit title.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like to transmit if an item is damaged via the
circulation status field. There is no specific code for a damaged item,
so we should use value 1 (other) along with an AF screen message to
describe the reason for the the circulation status of 1.
Test Plan:
1) Apply these patches
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: Christopher Kellermeyer - Altadena Library District <ckellermeyer@altadenalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In Koha, we represent on order items by giving those items a notforloan
value less then zero. We can use this to implement circ status 02 ( on
order ) in for SIP.
Signed-off-by: Christopher Kellermeyer - Altadena Library District <ckellermeyer@altadenalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In Koha, we can support circ status 09 in SIP by checking if the item's
location is "CART".
Test Plan:
1) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: Christopher Kellermeyer - Altadena Library District <ckellermeyer@altadenalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should remove the debug statements or use Koha::Logger when we want
to keep it.
Test plan:
Confirm that occurrences of remaining occurrences of DEBUG need to be
kept (historical scripts for instance)
Confirm that the occurrences removed by this patch can be removed
Confirm that the occurrences replaced by Koha::Logger are correct
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me, noting a few minor points on BZ.
JD amended patch: replace "warn #Finished" with "#warn Finished", and
put the statement on a single line
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 28572: Replace missing occurrence in misc/admin/koha-preferences
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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>
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>
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>
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 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>
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>
