Koha::Account->add_credit is expecting a positive amount.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Before the patch when one checks in something using the KOCT the last seen
date is not updated.
2) After the patch when one checks in something using the KOCT the last seen
date is updated.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In Koha 18.11 backdating a return triggered a recalculation of the fine. This was removed in bug 14591, and I believe it was in error. The bug report itself has no justification for the change in behavior.
Test Plan:
1) Disable CalculateFinesOnReturn
2) Backdate an overdue with fines, note the fine does not change
3) Apply this patch
4) Repeat step 2
5) The fine should be updated!
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We should use Koha::DateUtils instead of Date::Time directly
This patch simplay replaces calls to now() with a call to dt_from_string()
which does effectively the same thing.
Probably reading the code and verifying changes is sufficient but...
To test:
1 - confirm the files all compile
2 - confirm all tests pass
3 - confirm Koha still works
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In some tests we want to know if we are in a testing environment.
When run the usual way, our trick works, the perl interpreter matches 'prove':
$ENV{_} eq 'prove'
In other situations, we have the KOHA_NO_TABLE_LOCKS environment variables, for the SendCirculationAlert race conditions (see bug 15854 and bug 18364).
For unknown reasons, Jenkins runs the tests with /usr/bin/perl.
This patch suggests to rename KOHA_NO_TABLE_LOCKS and use KOHA_TESTING
instead, when prove is not used (or not correctly detected as it it the
case for Jenkins)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Verify on staff side that patron can be edited to opt in our out of auto renewal
2 - Check out some items to a patron opted in to auto renewal
3 - Ensure the items are checked out and set to autorenew
4 - Login on the opac at the patron
5 - Verify items cannot be renewed as scheduled for auto-renewal
6 - On staff side, opt patron out of auto renewal
7 - Verify on opac items are no longer marked for auto renewal
8 - Run the auto renewal cron job, items are not renewed
9 - Set 'no renewal before' to a setting that would prevent renewal
10 - Verify that opting patron in or out of auto renewal changes only the reason items cannot be renewed
11 - Set 'no renewal before' to a setting that would allow for renewal
12 - Verify that opting patron in/out changes their ability to renew
13 - Verify that when opted out cron does not renew
14 - Verify that when opted in the item is auto renewed
15 - Reset the due date, opt out, verify manual renewal succeeds
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patchset moves all code to calculate the correct renewal branch into Koha::Item.pm
When interface is opac we follow the syspref, otherwise we use the current userenv, or pass through
a defined branch
To test:
1 - Check out an item to a patron
2 - Set allowed renewals in the circ rules to 100 (just so you can keep testing)
3 - Renew the item in staff interface, confirm it is recorded correctly in statistics table (as signed in branch)
4 - Renew via the opac, testing with each setting of OpacRenewalbranch
5 - prove -v t/db_dependent/Koha/Item.t
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We do not need this subroutine, moving it where it is used.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Starting to replace the ModItem calls with Koha::Item->store
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds support for passing a trigger to
C4::Circulation::transferbook and passes 'RotatingCollection' to it when
called inside the rotating collections routine.
Test plan:
1/ Perform a rotating collection transfer operations
2/ Check the database for instances of 'RotatingCollection' in the
branchtransfers.reason field.
3/ Signoff
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds handling to catch transfers that may have been triggered
on item return.
Test Plan:
1) Enable AutomaticItemReturn and accompanying system preference
2) Return an item to the wrong branch and note the transfer
3) Check the database for the new trigger value
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Place a hold on an item
2 - Go to Circulation->Transfers
3 - Attempt to transfer item to a branch it is not expected at
4 - No warning
5 - Apply patches
6 - Repeate
7 - You get a notice that there is a hold and must deal with the hold (or ignore)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Looks like the atomicupdate and sysprefs.sql changes were lost at some point.
Don't forget to run QA tools on your patches before submitting
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates a request's status to RET upon return
Sponsored-by: Loughborough University
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Some rebase issues, accounttype no longer exists, circ rules make
CanBookBeRenewed fail, so we mock that too
interface must be passed as a hashref
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When the RenewAccruingItemWhenPaid syspref is enabled and all the fines
on an item that is accruing fines are paid, we automatically renew that
item to prevent it from starting to accrue fines again.
This patch adds an additional argument to C4::Circulation::AddRenewal
which allows us to skip the calculation of fines upon renewal, which we
don't want to do if the fines on that item have just been paid. Existing
calls to AddRenewal have not been amended because there seems to be a
convention of only passing undef when adding arguments that require
their positioning to be maintained. Since the new argument is the last
one, this is not the case with any existing call.
Sponsored-by: Loughborough University
Signed-off-by: Lucy Harrison <L.M.Harrison@lboro.ac.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To Test:
1) Place a hold on an item.
2) Check in the item to trigger the hold. Item is now listed as
waiting.
3) Set branch to a different library.
4) Check in the item to trigger the hold. Notice that nothing but a
local use is recorded.
5) Apply the patch.
6) Repeat steps 1-4. Notice that the hold is triggered around routed to
its original pickup location. A transfer is set and the hold status
is changed from waiting to correctly showing the item as in transit.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates the wording in the 'lost and found' process to more
closely reflect what the process is achieving by replacing 'RETURNED'
with 'FOUND'
Test plan:
1) Grep codebase for _FixAccountForLostAndReturned and note there are no
longer any instanced of it.
2) Run t/db_dependent/Circulation.t and note it passes
3) Test returning/renewing an item that has been marked as lost and note
the updated values in the accountlines now use LOST_FOUND as
credit_type_code and 'FOUND' as the status for the 'LOST' fee
(debit_type_code 'LOST')
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This necessitates moving the circ rules from using '*' to using
undef/NULL.
Signed-off-by: Minna Kivinen <minna.kivinen@hamk.fi>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Checkout an item with auto renewal set and eligible for auto renew
2 - Set no renewal before in the circ rules to 99 (something greater than the checkout period)
3 - perl misc/cronjobs/automatic_renewals.pl
4 - Check the statistics table, note the branch for renewal is null
SELECT * FROM statistics WHERE itemnumber={itemnumber} AND type='RENEWAL'
5 - Apply patch
6 - Repeat 1-4
7 - Note the branch is set to the issuing branch
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Ed Veal <eveal@mckinneytexas.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
0 - Do not apply this patch
1 - Check out an item to a patron
2 - Make sure a fee will be charged when lost
3 - Mark the item lost
4 - Make sure the fee will not be refunded on return of the item
5 - Return the item
6 - Check it out to a new patron
7 - Write off the fine for the original patron
=> The item is now checked in
8 - Apply this patch and repeat 1 to 7
=> The item is still checked out
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It appears that the transition to using Koha::Item in AddReturn has introduced a bug. Previously $item was a hashref with the key 'itemtype', now that it's an object, it has no itemtype method and so triggers an error with the message "The method Koha::Item->itemtype is not covered by tests!".
Test Plan:
1) Enable Branch Transfer Limits via itemtype
2) Check in an item
3) Note the error
4) Apply this patch
5) Restart all the things!
6) Check in an item
7) No error!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Maribeth (Turner) Shafer <mshafer@ckls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Use of uninitialized value $record_restrictions in uc at /kohadevbox/koha/C4/Circulation.pm line 3981
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
With bug 24217 pushed, lot of warnings appears during the tests are run.
Most of them are "Use of uninitialized value in "
Test plan:
Take a look at the output of run 1049
https://jenkins.koha-community.org/job/Koha_Master_D9/1049/consoleFull
Most of the warnings from this run will be removed by this patch
At least 2 are not fixed:
Use of uninitialized value in numeric eq (==) at /kohadevbox/koha/C4/Reserves.pm line 791.
t/db_dependent/Items_DelItemCheck.t => see 23463
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We absolutely need that for modules.
We are enabling strict by using Modern::Perl.
Note that other modules from C4 use strict and warnings, instead of
Modern::Perl
Test plan: git grep 2505 **/*.pm should not return any results
And let's see later what needs to be fixed.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If there is a limit for the number of suspension days
(maxsuspensiondays), the calculation is wrong. We are reducing the
number of days before taking into account the suspension charging
interval.
For instance, a checkin is 1 year late and the circ rules are defined to
charge 7 days every 15 days.
It results in 365 * 7 / 15 days of suspension => 170 days
Before this patch the calculation was:
365 * 7 limited to 333, 333 / 15 => 22 days
Test plan:
Given the examples in the commit messages and the description of the bug
report, setup complex circulation rules and confirm that the debarment
dates are calculated correctly
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
No changes expected here. For the next patch we are going to need to add
test and calculate the new debarment date. To ease the writing of these
tests the calculation is moved out of the existing subroutine.
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Wrong conflict resolution, the following
commit 6eade474ed
Bug 18276: Remove GetBiblioFromItemNumber - Easy ones
restored a previous change from
commit 546379cc92
Bug 17680: C4::Circulation - Remove GetItemIssue, simple calls
Not that "easy" or "simple"...
Test plan:
Run the test before and after this patch.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When you use the date picker or book drop mode and check in an item that is due on that date, a fine is assessed and not refunded.
For example: item 12345 is due on 11/19/2109 23:59. On 11/20/2019 I check the item in using date picker/book drop setting the check in date to 11/19/2019 23:59, the patron is charged a fine, and the fine is not cleared as would be expected, since the item is being checked in before it is overdue.
Test Plan:
1) Back date a checkout so it is overdue
2) Run fines.pl to generate the fine
3) Return the item, backdating to the same date/time is was due
4) Note the fine was not removed
5) Apply this patch
6) Repeat steps 1-3
7) Fine should be zeroed out now!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes the calculation of suspension expiration configuration
detached from the finesCalendar syspref. This way libraries have more
flexibility when setting circ rules.
I wrote this path as a bugfix, because the recent change pushed by bug 19204
changed this behavior and libraries have been complaining since they got
upgraded.
It is a minor change, just adding the new syspref, and replacing the
single place in which it is used for debarment calculation for the new
one.
The tests are updated similarly, just adding the new mocked syspref as
it was with the old one.
To test:
- Apply this patches
- updatedatabase
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> SUCCESS: Tests pass!
- Sign off :-D
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This adds the ability to alert a librarian of an item claimed as returned is actually returned.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We require next_open_day & prev_open_day to be more flexible. We could
create a separate sub, but that's not very DRY given that they'll do
pretty much the same thing.
So next_open_day becomes next_open_days and prev_open_day becomes
prev_open_days and both functions accept an additional parameter which
determines how many days they add or subtract.
All calls of these two functions have been modified accordingly.
Sponsored-by: Cheshire West and Chester Council
Sponsored-by: Cheshire East Council
Sponsored-by: Newcastle City Council
Sponsored-by: Sefton Council
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates the variable name '$branch' to '$branchcode' in a
number of places to make it clearer what the variable contains.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It looks like over progressive rebases of bug 20912 a clause was lost
within CanBookBeIssued such that a fatal error may be triggered if an
item with no corresponding itemtype was passed into the routine.
Additionally the we were passing a Koha::Library object to CalcDateDue
rather than a branchcode which resulted in a different duedate being
used in 'CanBookBeIssued' when compared to 'AddIssue'.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* Update C4::Accounts::chargelostitem
* Update C4::Accounts::manualinvoice
* Update C4::Circulation::_FixOverduesOnReturn
* Update C4::Circulation::_FixAccountForLostAndReturned
* Update C4::Overdues::UpdateFine
* Update C4::Overdues::GetFine
* Update C4::Overdues::GetOverduesForBranch
* Update Koha::Account->pay
* Update Koha::Account->add_debit
* Update Koha::Account->non_issues_charges
* Update Koha::Account::Line->apply
* Update Koha::Account::Line->adjust
* Update controller scripts
* Update reports scripts
* Update tests
Test Plan
1) Run the test suit and ensure everything still passes
2) Test reports/cash_register_stats still works
3) Test that adding manual invoices still works
4) Test that making payments still works
5) Test that lost item fee handling still works
6) Test that invoice printing still works
7) Test that the sco still works
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We should use the existing pattern of calling schema directly on
Koha::Database rather than creating a new object.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch starts a transaction and only commits if renewal and fines
updates and charges are successful (partial in any cna be problematic)
There is no feedback (as currently there is none either) but if part
fails, all fails.
I didn't include stats and notifications in the transaction, but we
could. (Edit JD: not true, they are included)
To test:
1 - Apply patch
2 - prove t/db_dependent/Circulation.t
3 - Attempt circs and renewals should be no difference
4 - If possible make part of transaction fail and ensure all fails
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended: commit title and one indendation (return statement)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When trying to transfer an unknown barcode in
/cgi-bin/koha/circ/branchtransfers.pl you get the error :
Can't call method "itemnumber" on an undefined value at
/home/koha/src/C4/Circulation.pm line 319.
This comes from C4::Circulation::transferbook which should stop when
finding unknown barcode.
Test plan :
1) Go to /cgi-bin/koha/circ/branchtransfers.pl
2) Enter a barcode not existing in database
3) Without patch you get a software error, with patch you get a message
saying 'No Item with barcode'
4) Enter a barcode existing in database and check transfer is OK
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Bin Wen <bin.wen@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
Run t/db_dependent/Circulation.t, t/db_dependent/Koha/Account.t,
t/db_dependent/Koha/Account/Lines.t and
t/db_dependent/api/v1/patrons_accounts.t and all should pass.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Circulation::TooMany gets itemtype from $item var beeing a Koha::Item unblessed.
When itemtype is at biblio level, calling $item->{'itemtype'} is wrong.
Test plan :
1) On a catalog with itemtype at item level : pref item-level_itypes=1
2) Create a biblio record with itemtype BOOK
3) Create an item on this biblio record with itemtype BOOK
4) Delete all issuing rules
5) Create a issuing rule with itemtype BOOK, any catagorie, any branch
6) Check-out the item
7) => Checkout is allowed
8) Check-in item
9) Change itemtype at biblio level : pref item-level_itypes=0
10) Check-out the item
11) => Checkout is not allowed
You see message "No circulation rule is defined for this patron and itemtype combination"
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to set an unlimited number of guarantors
for a given patron. As before, each guarantor may be linked to another
Koha patron, and all the behavior that applies to a given guarantor
remains the same.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Find some patrons with guarantors, verify the still have their guarantor
4) Test adding and removing guarantors on a patron record, both Koha users and not
5) Verify the "Add child" button works
6) Verify NoIssuesChargeGuarantees still works
7) Verify tools/cleanborrowers.pl will not delete a guarantor
8) Verify the guarantors are displayed on moremember.pl
9) Verify the guarantor is removed by members/update-child.pl
10) Verify the guarantor is removed by misc/cronjobs/j2a.pl
11) Verify import patrons converts guarantor_id, relationship, contactfirstname,
and contactsurname into a guarantor
12) prove t/Patron.t
13) prove t/db_dependent/Circulation.t
14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t
15) prove t/db_dependent/Items.t
16) prove t/db_dependent/Koha/Patrons.t
17) prove t/db_dependent/Members.t
18) prove t/db_dependent/Patron/Relationships.t
Signed-off-by: Kim Peine <kmpeine@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1. Set up an item type with a rental charge
2. Issue an item with that item type
3. Check fines, a charge of type 'Rent' will be visible with a
description of 'Rental'.
4. Renew the item
5. Check fines, a charge of type 'Rent' will be visible with a
description of 'Renewal of Rental Item TITLE BARCODE' where TITLE and
BARCODE are the items title and barcode.
5. Apply the patch
6. Repeat steps 1-4, charge descriptions should now be empty and charge
types should display 'Rental fee' and 'Renewal of rental item'.
7. Repeat steps 1-6 for an item type with a daily rental charge and note
the charge types are now 'Daily rental fee' and 'Renewal of daily rental
item'
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Matha Fuerst <mfuerst@hmcpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Matha Fuerst <mfuerst@hmcpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removed references to setting and getting the items.paidfor
field. Where it was used for display, in moredetail.pl, we replace it
with a query on the accountlines.
Test plan:
1) Apply patch
2) Pay off a LOST item
3) Check for the associated display of 'Paidfor?:' on the itemdetails
page
4) Writeoff a LOST item
5) Check that a 'Paidfor?:' is not displayed on the itemdetails page.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Up until now we marked lost items as returned in the accountlines, now
we have the oportunity to mark these distinctly with an appropriate
status we should.
Test Plan
1) Find an overdue with fines
2) Ensure you are not forgiving fines when an item is marked as lost
3) Mark the item as lost
4) Confirm the Fine is given a status of 'Lost'
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Convert 'L' to 'LOST' to become more descriptive in it's use.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch will move the list item refund rules from a dedicated table to the circulation_rules table.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Verify lost item refund rules remain unchanged
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If a lost item fee is written off, it creates a writeoff with the same itemnumber but the amount column is a negative number.
Now, when the lost item is returned, it calls _FixAccountForLostAndReturned which searchs for all accountlines with an account type of 'L' or 'W'.
Then, if the *first* of those lines has an outstanding balance, a credit is created and *all* the lines found are passed to $credit->apply. The apply method then calls is_debit on each line and when it hits the writeoff, it throws an exception ( Koha::Exceptions::Account::IsNotDebit ).
When this happens, the credit is creating but not applied the the outstanding lost item fee, and the librarian is presented with an error page.
It seems like the solution is to only fetch the first result since it seems like that is the only one we should be operating on.
Test Plan:
1) Create a lost item with a fee
2) Create a manual debit using the barcode of the item
3) Write off that manual debit
4) Check in the item, note the error
5) Apply this patch
6) Repeat steps 1-3
7) Check in the item, no error!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test Plan:
1) Apply dependancies
2) Apply this patch set
3) Run updatedatabase.pl
4) Ensure holdallowed and hold_fulfillment_policy rules behavior remains unchanged
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test Plan:
1) Checkout an item to a patron
2) Ensure the item has a replacement cost (or itemtype has default)
3) Ensure patrons are charged when items lost
4) Mark the item lost
5) Confirm patron has a fine
6) Write off the fine
7) Delete the patron
8) Check in the item
9) Note the internal server error
10) Apply this patch
11) Repeat steps 1-8
12) Note there is no internal server error!
13) prove t/db_dependent/Circulation.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Not kidding, it's again, and will certainly appear more.
The problem is that we should have a NULL value in DB to make things
more readable and logical. Now we need a quick fix.
Test plan:
Set "Current checkouts allowed" to unlimited (empty string)
Try to check an item out
=> Without this patch we are blocked with a "too many" message
=> With this patch applied the correct behavior is back!
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1 - Issue an item to a patron with a backdated due date
2 - Run fines.pl - note you generate a fine for the patron
3 - Run longoverdue.pl - make sure MarkLostItemsAsReturned is turned off
and to charge
4 - Confirm the patron has a lost fee and an overdue
5 - Return the item
6 - With patch applied, patron should now have 1 overdue fine and 1 lost fine
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Almost everywhere we call IsAvailableForItemLevelRequest we already have
a Koha::Patron and Koha::Item object. It makes sense to use them to
avoid a refetch
Test plan:
It would be good to test this patch on top of 19300 and 19301 and make
sure everything works as expected
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch fixes remaining cases of the list => scalar change.
To test:
- Run:
$ kshell
k$ prove t/db_dependent/Holds/HoldFulfillmentPolicy.t t/db_dependent/Reserves.t
=> FAIL: Tests fail
- Apply this patch
- Run:
k$ prove t/db_dependent/Holds/HoldFulfillmentPolicy.t t/db_dependent/Reserves.t
=> SUCCESS: Tests pass
- Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Prior to this patch the exemptfine option for_FixOverduesOnReturn would
directly set the overdue amount to 0 rather than creating an appropriate
credit of the type forgiven and offseting it against the debt.
Test Plan:
1) Find a checkout that is overdue with fines
2) Check the item in with the forgive fines option checked
3) Note that the users account details now shows the overdue as forgiven
and a forgiven credit is added which matches the overdue amount (and is
applied against it, i.e. both overdue and forgiven lines have 0
amountoutstanding).
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a new syspref "UpdateItemLocationOnCheckin" which
accepts pairs of shelving locations. On check-in the items location is
compared ot the location on the left and, if it matches, is updated to
the location on the left.
This preference replaces ReturnToShelvingCart and
InProcessingToShelvingCart preferences. The update statement should
insert values that replciate these functions. Note existing
functionality of all items in PROC location being returned to
permanent_location is preserved by default. Also, any items issued from
CART location will be returned to their permanent location on issue (if
it differs)
Special values for this pref are:
_ALL_ - used on left side only to affect all items
_BLANK_ - used on either side to match on/set to blank (actual blanks
will work, but this is an easier to read option)
_PERM_ - used on right side only to return items to permanent location
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Set the new system preference UpdateitemLocationOnCheckin
to the following (assuming sample data):
NEW: FIC
FIC: GEN
4) Create an item, set its location to NEW
5) Check in the item, note its location is now FIC
6) Check in the item again, note its location is now GEN
7) Check in the item again, note its location remains GEN
8) Test using _ALL_, _BLANK_ and _PERM_ for updates
9) Try entering various incorrect syntax in the pref and note you are warned
Sponsored by:
Arcadia Public Library (http://library.ci.arcadia.ca.us/)
Middletown Township Public Library (http://www.mtpl.org/)
Round Rock Public Library (https://www.roundrocktexas.gov/departments/library/)
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The condition in TooMany applied branch limits only if the rule didn't have a branchcode, this was wrong
To test:
1 - Find a title in the catalog, add 8 items, all of a single itemtype, 4 for branch A, four for branch B
2 - Remove any specific circ rules
3 - Set a default circ rule for the itemtype used above, limiting the max issue quantity to 3
4 - Find a patron and checkout the items from branch A
5 - You should be allowed to checkout 3, but the fourth should trigger 'too many'
6 - Now checkout the items from branch B, again you can checkout 3 and not four
7 - Apply this patch
8 - Assuming you have 6 items out now, try one from either branch, you should trigger 'too many' and have 6
9 - Return two from branch B and one from branch A
10 - Now you have three items issued total
11 - An item from either branch should be refused now
12 - Test with different values of 'CircControl' and confirm your expectations are met
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Some libraries don't want to force the librarians to manually confirm
each checkout when the item is checked out to another. Instead, they
would prefer to be alerted after the fact.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Enable the new syspref AutoReturnCheckedOutItems
4) Check an item out to a patron
5) Check the same item out to another patron
6) Note you are not prompted to confirm the checkout,
but are instead alerted that is had been checked out to another patron!
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: BWS Sandboxes <ByWaterSandboxes@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch removes the hardcoded untranslatable string
'Lost item' from C4/Circulation.pm.
To test:
1) Make sure the system preference WhenLostChargeReplacementFee is set to Charge
2) Optional: in Administration > Item types, add a default replacement cost to
the item type you plan to use
3) Loan an item out to a patron
(If there is no default replacement cost, make sure the item has a replacement
price)
4) In the patron's account > Details > Loans, click on the item's barcode
5) Set the lost status to Lost
6) Go back to the patron's account > Fines
7) Notice it is written 'Lost item , Lost item title barcode (title)'
8) If you have another language installed, switch to the other language
and notice the second Lost item is still in English
9) Apply the patch
10) Redo steps 3-6
11) Notice it is written 'Lost item, title barcode (title)'
12) Optional: switch to another language, notice there is no English string
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
We missed a change in calling parameters passed to CalcDateDue in AddRenewal
during the initial QAing. This patch corrects the call and adds a test to catch
regressions.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds the 'interface' field to the accountlines table and
updates all Koha::Object routines and calls to use it.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
I went back over 12 years to and still only found "FIXME: What are these
accounttypes" concerning the 'O' type and I couldn't find anywhere where
it was being set.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
A series of ternaries were introduced when we moved to add_debit which
defaulted to 'user 0' should a userenv not be set. This was incorrect
as userenv may well not be set (during cronscript runs for example) and
the new constraint would not allow such a default. We switch to 'undef'
here to satisfy the constraint.
Test plan
1) Ensure you have data in your system that would be caught by the
longoverdues cronjob.
2) Ensure you're sysprefs are setup to charge for lost items
3) Run the script and varify it runs to completion without errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Play with fines, should work OK
2) Try to print receipts on fines - prinfeercpt.pl, printinvoice.pl
3) git grep getnextacctno -> no occurences
4) git grep accountno should return only:
installer/data/mysql/atomicupdate/bug_21683_remove_column_accountno.perl
installer/data/mysql/update22to30.pl
misc/release_notes/release_notes_3_10_0.txt
misc/release_notes/release_notes_3_22_0.txt
5) prove
t/db_dependent/Accounts.t
t/db_dependent/ILSDI_Services.t
t/db_dependent/Stats.t
t/db_dependent/Koha/Account.t
Rescued-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
We were passing around possibly undefined $return_date variables from
AddReturn and then instantiating a new DateTime object as a default for
each routine. This followup sets the default higher up the stack within
AddReturn which provider clearer logic and a small performance
improvment.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The automatic rebase after bug 21206 required a helping hand.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch updates the tests the ensure we do not double charge for
renewals that take place before the original due date and fixes the
corresponding loging in C4::Circulation::AddRenewal.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Increase test coverage for CanBookBeIssued and fix a introduced during
the refactoring to Koha::Fees.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In preparation for the introduction of Koha::Charges::Fines I have moved
this ::Fees class into the Koha::Charges:: namespace
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Some libraries would like to be able to charge a rental fee based on the
number of days an item will be checked out, as opposed to the flat fee
currently offered by Koha.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Edit an itemtype, add a daily rental fee of 1.00
4) Check an item of that itemtype out for 7 days
5) Verify the patron now has rental fee of 7.00
Signed-off-by: Matha Fuerst <mfuerst@hmcpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Known Side Effect: Prior to this patch renewal charges were not
recorded in the FinesLog. After this patch, if the FinesLog is
enabled then the 'action' will be recorded as `create_rent`.
Sponsored-by: PTFS Europe
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
There was previously an ambiguity between the branch/category/itemtype
specific max{,onsite}issueqty and the total-per-patron max{,onsite}issueqty.
The latter has been renamed to patron_max{,onsite}issueqty.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch set moves maxissueqty and maxonsiteissueqty to the
circulation_rules table.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) prove t/db_dependent/Circulation.t
4) prove t/db_dependent/Circulation/Branch.t
5) prove t/db_dependent/Circulation/GetHardDueDate.t
6) prove t/db_dependent/Circulation/Returns.t
7) prove t/db_dependent/Circulation/SwitchOnSiteCheckouts.t
8) prove t/db_dependent/Circulation/TooMany.t
9) prove t/db_dependent/Holds/DisallowHoldIfItemsAvailable.t
10) prove t/db_dependent/Reserves.t
11) Note no changes in circulation behavior related to check out limis
both on and off site
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Known Side Effect: Prior to this patch issuing charges were not
recorded in the FinesLog. After this patch, if the FinesLog is
enabled then the 'action' will be recorded as `create_rent`.
Sponsored-by: PTFS Europe
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Fix conflict with
commit f8544ba579
Bug 21999: Move attributes to a variable to not dup them
Thanks tests!
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
prove t/db_dependent/Circulation.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Note: This is here for information purpose, feel free to test it if you
wan to play with it.
TODO: C4::Reserves::_get_itype is not longer in use
No more GetItem must be returned by:
git grep GetItem|grep -v GetItemsAvailableToFillHoldRequestsForBib|grep
-v GetItemsForInventory|grep -v GetItemsInfo|grep -v
GetItemsLocationInfo|grep -v GetItemsInCollection|grep -v
GetItemCourseReservesInfo|grep -v GetItemnumbersFromOrder|grep -v
GetItemSearchField|grep -v GetItemTypesCategorized|grep -v
GetItemNumbersFromImportBatch|cut -d':' -f1|sort|uniq
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
issues.lastreneweddate is a datetime and we could record the time part
of the date.
Test plan:
Renew an issue
note that the time part of the last renewed date is set correctly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
Try to upload koc file with some returns
Success: the file should be correctly processed
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The $circControlBranch variable was originally set to be used to pick
the right dropbox branch. It was only used in MarkIssueReturned, to get
the right Koha::Calendar object. As this responsability was moved top to
the AddReturn caller, and the fact that _GetCircControlBranch is
actually used for fines rules, there's no use for it in this context.
And it was left on the previous patch as a mistake.
To test:
- Make sure the variable is not actually used:
$ git grep '$circControlBranch'
=> SUCCESS: removed variable is not actually used.
- Sign off :-D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch changes the params accepted by
C4::Circulation::MarkIssueReturned by removing the $dropbox_branch
param.
This passed branchcode was only used to initialize the Koha::Calendar
object, but the date arithmetic has already taken place in a couple
places before we reach this point. This logic needs to be simplified
(bug 14591), and this is the starting point.
To test:
- Apply this patch
- Run:
$ git grep MarkIssueReturned
=> SUCCESS: Check all the uses of the function either originally passed
undef, or now pass the same date that would've been calculated anyway,
in the returndate param.
- Run:
$ kshell
k$ prove t/db_dependent/Circulation/MarkIssueReturned.t
=> SUCCESS: Tests pass!
- Sign off :-D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Avoid c/p as much as possible :)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes _FixAccountForLostAndReturned reconcile the patron's
account balance, when the AccountAutoReconcile syspref is set.
To test:
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> SUCCESS: Tests pass, peace \o/
- Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> FAIL: branchcode is not set
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> SUCCESS: Tests pass!
- Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
For the purposes of statistics, it appears that it would help many
libraries to have branchcode recorded in the accountlines table. For
payments, the field would contain the code for the branch the payment
was made at. For manual invoices, it would be the code of the library
that created the invoice.
Test Plan:
1) Apply this patch set
2) Create and pay some fees
3) Note the branchcode for those fees and payments is set
to your logged in branch
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This is an alternative to bug 21732 as transfers are automatically cancelled on marking an item lost, and the items holding rbanch is set to the transfers source ('from') branch.
When an item is marked as lost, the routine should also clean up any
outstanding transfers.
Also added tests to t/db_dependent/Circulation.t which check:
* If transfer is automatically deleted when item is marked as lost
* If the items holdingbranch automatically changes when item with
transfers on it is marked as lost.
Test plan:
1. Find a item which is in transfer, i.e. find an item with the text in
the 'Status' field of the table in detail.pl that indicates it is in
transfer
2. Set the item to 'Lost' either by clicking on Edit->Edit items from
the detail.pl page
OR
clicking on the Items tab on the left side of the detail.pl page
3. Notice that the transfer is now cancelled for the item and the items
holdingbranch is the transfers source ('from') branch
4. Run t/db_dependent/Circulation.t
Sponsored-by: Brimbank Library, Australia
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
(fixed the introduction of a whitespace line and removed a double
declare warning from the new tests as part of QA)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Make sure WhenLostChargeReplacementFee is set to charge
2 - Find an item with a replacement cost (or default) and a call number
3 - Checkout the item to a patron
4 - Mark the item lost
5 - View the fine - the description includes title and barcode
6 - Apply patch
7 - Check the item in
8 - Check it out again
9 - Mark it lost
10 - Note the fine includes the callnumber
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch changes the behaviour in the _FixAccountForLostAndFound
method.
The method will now add the amountoutstanding value for the lost item
fee to the CR credit to be generated. This means that:
- If there's some remaining debt, the same amount will be added to the
CR credit and used to cancel that debt. The final amountoutstanding
will be the same as before, but an offset will be generated as
required.
- If the line was written off, the behaviour remains unchanged, so no
offset.
- If the line was payed and/or written off in full only the payments are
refund, preserving the current behaviour.
To test:
- Apply the regression tests patch
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> FAIL: Tests fail because the behaviour is not correct
- Apply this patch
- Run:
k$ prove t/db_dependent/Circulation.t
=> SUCCESS: Tests now pass!
- Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Came across those calls in bug 20598 in _FixOverduesOnReturn
Koha::Account::Offset->new(
{
debit_id => $accountline->id,
type => 'Forgiven',
amount => $amountoutstanding * -1,
}
);
This does nothing if you don't store data.
Test Plan:
1) Apply this patch
2) Set up 2 items with overdue fines
3) Return one with dropbox mode
4) Note the dropbox account offset is created
5) Return one with full fine forgiveness
6) Note the forgiven account offset is created
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
[1] Correct POD for _FixOverduesOnReturn
Is called by AddReturn, AddRenewal and LostItem.
Also tested in Circulation.t btw
[2] $dbh is not used in _FixOverduesOnReturn
[3] Moving all parameters to the first line.
[4] Variable $uquery is not used too.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test Plan:
1) Ensure WhenLostForgiveFine is disabled
2) Create an overdue with a fine
3) Mark it lost with longoverdue.pl
4) Note it is still marked as an accruing fine
5) Apply this patch
6) Repeat steps 1-3
7) Note it is no longer an accruing fine!
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Followed the test plan and it works.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
We have the itemnumber no need to pass the issue_id, we can retrieve it
from chargelostitem
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Accounts.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
[EDIT:]
Patch should have increased the number of tests obviously.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - prove -v t/db_dependent/Koha/Config/SysPrefs.t
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
[1] Fix two typos in Circulation.t.
Although the test does not fail, line 2127 contains two typos.
Changing INVISILE to INVISIBLE :)
And type should be itype.
[2] Remove $yaml as leftover from older code.
[3] Add a next when the split on /:/ does not give two results. This will
prevent uninit warnings (although still disabled now in Circulation).
[4] For the same reason we should switch the lines for NULL and empty
string. The undefs you insert should trigger a warn.
[5] The line for empty string should not insert undef, but empty string.
For the same reason adding the condition defined($_) ...
And proving it by adding two tests for the opposite values of
callnumber and itemnotes.
[6] Adding a strip spaces around the fieldname. User friendly..
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch changes the logic inside the method, to make it match the
behaviour described on the tests.
It uses the existing offsets on the account_offsets table to gather
information about the right things to refund.
To test:
- Run:
$ kshell
k$ prove t/db_dependent/Circulation.t
=> FAIL: Tests don't pass!
- Apply this patch
- Run
k$ prove t/db_dependent/Circulation.t
=> SUCCESS: Tests pass!
- Sign off :-D
Followed test plan, patch works as described. All three patches pass QA
test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch substitutes C4::Accounts->getnextacctno for
C4::Accounts::getnextacctno since getnextacctno is only expecting to be
passed a borrowernumber
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes the same change as the main patch, just for an
additional occurance of getnextacctno
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1. Fetch and checkout the master branch
2. Checkout an item with a rental charge associated with it to a user
and notice an error is thrown
3. Apply patch
4. Restart memcached and plack
5. Repeat steps 1 and 2 and notice the checkout happens successfully
Sponsored-By: Catalyst IT
Signed-off-by: Andrew Isherwood <andrew.isherwood@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
What we were doing was wrong and is still wrong. The output_pref should not be done
in modules or script, only template side.
Much more work would be needed to clean the situation. This patch provides less changes
as possible to, hopefully, not introduce side-effects.
To recreate:
1 - Enable decreaseLoanHighHolds, set to 1 day and more than 0 holds
2 - Set TimeFormat to 12 hour
3 - Find or create a record with two items
4 - Place a hold on one of them
5 - Checkout the other to a different patron
6 - Note the warning message display correct time
7 - Confirm the checkout
8 - Note the item is due at 11:59AM
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
When the syspref BlockReturnOfLostItems is set to Block, the item is blocked from being returned, but is still considered found -- it's set to lost=0 and a refund is applied to the patron (if circ rules allow). The item can then be checked in a second time and returned as it is no longer lost.
Test Plan:
1) Set an item to lost
2) Set BlockReturnOfLostItems to Block
3) Check the lost item in
4) Checkin message should say item is lost and cannot be returned
5) Check lost status of item, it should remain unchanged
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If an item is no longer issued but somehow still has a date in the onloan
column, checking it in should clear that date.
Adding a ModItem call in the NotIssued section.
Test plan:
[1] Run t/db_dependent/Circulation.t
[2] Bonus: Checkout item, delete issue from table, checkin. Verify that
items.onloan has been cleared.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Re-did the patch to follow best practices.
TEST PLAN:
0. Apply first patch only
1. prove t/db_dependent/Circulation.t
2. Apply second patch
3. prove t/db_dependent/Circulation.t
prove should fail the first time and pass the second time.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
t/db_dependent/Holds/RevertWaitingStatus.t ..
Undefined subroutine &C4::Circulation::MoveReserve called at /home/vagrant/kohaclone/C4/Circulation.pm line 1316.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Due to a simple typo, the accountline passed to Koha::Account::pay from _FixAccountForLostAndReturned is not used. That means that the credit for the lost item fee may be applied to other fees before it is used on the lost fee itself.
Test Plan:
1) Find a patron with existing fines
2) Ensure your settings will charge patrons for lost items
3) Check out an item to a patron with existing fees that need paid
4) Mark the item lost, charging the lost item fee
5) Return the item
6) Note the fee was refunded, but it paid down earlier fines first,
and not the lost item fee first
7) Apply this patch set
8) Repeat steps 1 - 5
9) Note the lost item fee is the first fee to be paid off by the lost
item fee refund
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Followed the test plan and it works as expected.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
1. Item type defined at item level (item-level_itypes=1)
2. Mark an item type not for loan (itemtypes.notforloan=1)
3. Checkout an item using this item type (items.itype="BK" for instance)
=> Checkout is not blocked!
I suspect
commit 3953fdb921
Bug 19943: Remove itemtype vs itype confusion in CanBookBeIssued
to be the root of this issue.
One occurrence of $item->{itemtype} has not been replaced.
In this case it refers to the biblioitem->{itemtype} value whereas we want to use
$item->{itype}. So this issue does not happen if items.itype==biblioitem.itemtype
(just in case you are not reproducing the problem).
Test plan:
Make sure not for loan items cannot be checked out
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
On bug 19943:
- elsif ($biblioitem->{'notforloan'} == 1){
+ elsif ($biblioitem->notforloan == 1){
The biblioitems table does not contain a notforloan column, this comes
from the item type.
This bug only appears when item type is defined at biblio level
(item-level_itypes=0)
Test plan:
Set item-level_itypes = biblio
Check an item out
Without this patch it explodes with
"The method notforloan is not covered by tests!"
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I reproduced the error condition and verified the tests failed without
this patch. After this patch is applied, tests pass and checkout
succeeds.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patchs adds the ability to calculate the end of the suspension date
(debarment date) using the finesCalendar syspref.
Prior to this patch it was never calculating without taking into account
the calendar.
calculated without taking holidays into account.
This was a problem because the restriction could end in the middle of a
period the library is closed.
Test plan:
- Set finescalendar to 'not including days the library is closed'
- Set a circulation condition with no fine/maxfine, but fine days and
max fine days instead
- Check out an item with a due date in the past
- Check the item in and verify the restriction date
- Clean the restriction
- Add holidays to your calendar on the calculated restriction date
- Check the item out again with the same due date in the past
- Check in the item again
- Verify the calculated restriction end date has changed, it's set to the day
after the holiday.
Fines in days restriction calculation is correctly taking calendar
into account.
Sponsored-by: Goethe-Institut
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Given the confusion regarding this behaviour it sounds better to make it
configurable.
This pref will take 4 different values, 1 per place an item can be
marked as lost.
Test plan:
Mark items as lost and confirm the item is returned or not, depending on
the value of the system preference.
- from the longoverdue cronjob (--mark-returned takes precedence if set)
- from the batch item modification tool
- when cataloguing an item
- from the items tab of the catalog module
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not need to pass all those parameters, just the checkout object is
enough.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Apply this patch
2) Assign a charge to an item type
3) Checkout an item of that type to a patron
4) View the accountlines table for that patron
SELECT * FROM accountlines WHERE accounttype='Rent' and borrowernumber=##;
5) Note there is an issue_id
Or
1) Apply this patch
2) prove t/db_dependent/Circulation/issue.t
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN
---------
See comment #1
Applying the test without the patch: messy.
Applyin both patches: smooth.
Run koha qa test tools
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We already have a chargeperiod (Fine charging interval) value which is
taken into account for fine ($) for not for the suspension period.
This patch adds a new column suspension_chargeperiod (Fine day charging
interval) to add the same behaviour when a suspension is calculated.
Test plan:
Add overdue item and play with the circulation rules (and the calendar).
The suspension period must be correctly calculated.
Please provide the different tests you made.
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The system preference CataloguingLog is not recommended for use in
production. This is do to the fact that every checkin and checkout
generates one or more log entires. This seems to be not only bad
behavior, but unnecessary and outside the needs of CataloguingLog as we
have CirculationLog.
Test Plan:
1) Log into staff client
2) Home -> Koha administration -> Global system preferences -> Logs
3) Set only CataloguingLog to 'Log', everything else to "Don't log"
4) Click 'Save all Logging preferences'
5) In MySQL, use your instance DB, and then type 'delete from action_logs;'
6) Have a person checkout and checkin anything.
7) In MySQL, 'select * from action_logs;'
-- there will be data. This is the floodiness that will be removed.
8) Apply this patch
9) Repeat steps 5-7
-- there should be no data.
10) Edit any biblio or item.
11) In MySQL, 'select * from action_logs;'
-- there should be data reflecting the changes made.
12) run koha qa test tools
NOTE: Improved clarity of test plan -- Mark Tompsett
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The biblioitem's info can be retrieved with Koha::Biblio->biblioitem
Test plan:
1. Use the age restriction to restrict checkouts for a given patron
2. Check some items of a biblio out, go to "Items" tab, then "View
item's checkout history" link. Compare views with and without patches
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Just a preliminary step to clean the code a bit in CanBookBeIssued.
The effective item type is already set from GetItem and we do not need
to deal with that again.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The change is trivial here, we only want to pass gonenoaddress, lost and
is_debared to the template.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Before this patchset, DEBT was formatted in the module, now it should be
done template-side.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As said previously, GetMemberAccountBalance returns ( the balance, the
non issues charges, the other charges)
The other charges are the balance - the non issues charges.
In this patch we remove the subroutine from C4::Members and use the
new Koha::Account->non_issues_charges subroutine instead
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The GetMemberAccountRecords may be a perf killer, it retrieves all the
account lines of a patron and then the related item and biblio
information.
Most of the time we only want to know how much the patron owns to the
library (sum of amountoutstanding). We already have this information in
Koha::Patron->account->balance.
This patch replaces the occurrences of this subroutine by fetching only
the information we need, either the balance, the detail, or both.
It removes the formatting done in the module, to use the TT plugin
'Price' instead.
There is a very weird and error-prone behavior/feature in
GetMemberAccountBalance (FIXME): as the accountlines.accounttype is a
varchar(5), the value of the authorised value used for the
ManInvInNoissuesCharge pref (category MANUAL_INV) is truncated to the 5
first characters. That could lead to unexpected behaviors.
On the way, this patchset also replace the GetMemberAccountBalance
subroutine, which returns the balance, the non issues charges and the
other charges. We only need to have the balance and the non issues
charges to calcul the third one.
Test plan:
Add several fees for a patron and play with HoldsInNoissuesCharge,
RentalsInNoissuesCharge and ManInvInNoissuesCharge.
The information (biblio and item info, as well as the account line) must
be correctly displayed on the different screens: 'Fines' module, fine
slips, circulation module
Note that this patchset could introduce regression on price formatting,
but will be easy to fix using the TT plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should call Koha::Patron->is_expired in CanBookBeIssued instead of
doing the same calculation.
Tests have been adapted to pass with new SQL modes.
We should not need to update the values in DB, we already have
Bug 14717: Prevent 0000-00-00 dates in patron data (3.21.00.023)
Test plan:
prove t/db_dependent/Circulation/dateexpiry.t
prove t/db_dependent/Koha/Patrons.t
must return green
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Fix for:
'koha_kohadev.b.title' isn't in GROUP BY
t/db_dependent/Circulation/GetTopIssues.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
More attention needed here!
Fix for:
Non-grouping field 'days_until_due' is used in HAVING clause
t/db_dependent/Circulation.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Feature using it is completely undocumented as far as my research has
shown.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We need to make subroutine from C4 use more Koha::Object objects
Seeing bug 19276, starting here is a good start.
Test plan:
The tests should still pass.
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the patron's account has expired and BlockExpiredPatronOpacActions is set,
we expect auto renewal to be rejected.
Test plan:
Use the automatic_renewals.pl cronjob script to auto renew a checkout
Before this patch, if the patron's account has expired the auto renew was done.
With this patch, it will only be auto renewed if BlockExpiredPatronOpacActions is not set.
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If on-site checkouts are set to unlimited (i.e. NULL/undef), they are
currently blocked.
Test plan:
1/ Set All/All rule with Unlimited/unlimited for normal/onsite checkouts
2/ Will be able to perform onsite checkout
3/ Edit rule to be 15/Unlimited normal/onsite
4/ Will be able to perform onsite checkout
=> Without this patch it was blocked
5/ Set rule to 15/15
6/ Onsite checkouts work again
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries wish to track what the current location of items was at the time they were checked out. This will help libraries track which physical locations in the library patrons are more likely to check out a given book from.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Check out an item that has a location set
4) Renew that item
5) View the checkout and renewal in the statistics table,
verify each has the location column populated correctly
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Mimicking what does BlockReturnOfWithdrawnItems we can easily add a new
syspref to block return of lost items.
This patch adds BlockReturnOfLostItems, if set to 'Block' a item marked
as lost cannot be checked in.
Test plan:
1/ Set BlockReturnOfLostItems to 'Do not block'
2/ Check an item out to a patron
3/ Edit the item and mark it as lost (*)
4/ Check the item in
=> The item is checked in
5/ Edit the item and remove the lost status
6/ Check the item out again
7/ Edit the item and mark it as lost (*)
8/ Check the item in
=> The item is not checked in
(*) There are 2 ways to mark an item lost:
- From the item list view (/catalogue/moredetail.pl?biblionumber=42)
If you set the lost status from this form, the issue will be returned
Maybe this should be optional (?)
- From the edit items form (/cataloguing/additem.pl?biblionumber=42)
It is the form you must use to not mark the issue returned.
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Dominic Pichette <dominic@inlibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
[1] Replace corrosponding => corresponding
[2] Replace containts => contains
[3] Replace item_level-itypes => item-level_itypes
[4] Replace Managment => Management
[5] Replace should returns => should return
Test plan:
Note that this patch only deals with POD lines or test descriptions.
So there is nothing to test, just read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Patch amended by RM: The release notes should not be modified
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are several ways to mark an item an lost:
- item list view (catalogue/moredetail.pl, "Items" tab)
- cataloguing (cataloguing/additem.pl)
- Batch item modification tools (tools/batchMod.pl)
- The long overdue cronjob (misc/cronjobs/longoverdue.pl)
So far only the cronjob is configurable, the others mark the item as
returned (does the checkin).
This behaviour should be controlable using a syspref, to let libraries
choose what fit best for them.
Test plan:
Use the 2 options of the pref, mark checked out items as lost using the
different possibilities, and confirm that the behaviours make sense to
you
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The account offsets table should be used to track increments and
decrements of fines via payments and credits, as well as fine accruals.
It should be able to match fees to payments and visa versa, so we can
know which fee was paid by a given payment, and which payments applied
to a given fee.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) Note the table accountoffsets has been renamed to account_offsets
4) Ensure fine generation creates offsets
5) Ensure creating a manual invoice creates an offset
6) Ensure a lost item charge creates an offset
7) Ensure Reverse Payment creates an offset
8) Ensure a payment creates an offset
9) Ensure a payment for multiple fees creates an offset for each
10) Ensure writeoffs create offsets
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This has been raised by failures on t/db_dependent/Circulation/issue.t
(thanks tests!)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To recreate:
1 - Manually add a lost fine to a ptron and include a barcode
2 - Attempt to write off the fine
3 - Internal server error
4 - Checkout an item and mark lost to checkin and fine
5 - Attempt to write off line
6 - Internal server error
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves some code and prevents checking for too many checkouts
when performing a renewal via checkout
To test:
1 - Set a rule to limit checkouts to a single issue, allowing renewal
2 - Issue an item to a patron
3 - Issue the same item
4 - In staff client you get a confirm to renew and a notice of Too Many
checkouts, don't confirm
5 - VIA Sip - you get a renewal response, but in logs the renewal fails
as a 'too
6 - Apply patch
7 - Via staff client you shoudl get renewal confirm with no too many
error
8 - SIP checkout should renew
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Nothing important here, but this line should have been removed by bug
18966:
2177 # Update the fines
2178 $dbh->do(q|UPDATE accountlines SET issue_id = ? WHERE
issue_id = ?|, undef, $old_checkout->issue_id, $issue->issue_id);
The issue_id is now the same when moved from issues to old_issues. We do
not need to update the accountlines table.
No test plan here, you need to understand previous changes to validate
this patch.
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>
Bug 17829 must have been handle this specific case: GetMember set
category_type, but now $borrower is a Koha::Patron unblessed and does
not contain the category_type.
The fix is to call ->category->category_type on the Koha::Patron object
to be able to know if they are a statistic patrons.
Test plan:
Run the tests
Tests pass, as does QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The statement for head3 NB ('nota bene'?) looks like a hash key
in the list of possible return values for $needsconfirmation.
Moved it up and prefixed it with IMPORTANT.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The returns from C4::Circulation::CanBookBeIssued used
to be structured as a hashref of entries like
REASON => {
data => 'foo',
moredata => 'bar',
};
Some entries still are. But many are now
REASON => 1,
data => 'foo',
moredata => 'bar',
The sip Checkout routine still assumed the former, as it
reports any causes it was not aware of (to maintain support for
a changing api) The data fields could leak into the screen message
field of the response. e.g. the borrowernumber or surname of the
borrower who has a hold on an issued title. Some real messages were
getting obscured by this
This patch sanatizes the return from from CanBookBeIssued
by removing keys which are not all uppercase
It also fixes a case where the key's data element was used
for the screen message when we should use the key itself
Updated the documentation of CanBookBeIssued to flag up
the assumption re case and the fact that 3 elements rather
than two may be returned
The loop through the returned keys was a bit bogus
so we now explicitly jump out if noerror is unset
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested quite extensively. Test results put on Bugzilla.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently AddIssue tests if renewal, but logs an issue even if so. This
patch moves the logging into the conditional so a log entry is only
added if we aren't renewing (as renewals are logged separately)
To test:
1 - prove t/db_dependent/Circulation.t - one test should fail
2 - Enable both issue and renewal logs
3 - Checkout an item to a patron
4 - View the logs - the issue is captured
5 - Checkout the item to the patron again and confirm renewal
6 - Both an issue and a renewal are logged
7 - Apply patch
8 Repeat 1-6, tests should pass and only renewal should be logged
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As Jonathan pointed out, GetItem already called effective_itemtype.
So we can just use $item->{itype} here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In the regular situation, you can get itemtype via biblio and then
biblioitem as well as via biblioitem (at least when item-level_itypes
is set to biblio).
But since Koha unfortunately defined two relations in item, one for
biblioitemnumber (the good one) and one for biblionumber (redundant),
TestBuilder (correctly) builds one biblioitem and two biblios.
If you item-level_itypes to biblio record, this will result in failing tests
when calling AddReturn (in this case Koha/Patrons.t).
It will crash on:
Can't call method "itemtype" on an undefined value at C4/Circulation.pm line 1826.
Cause: AddReturn goes via the biblionumber to biblio and than to
biblioitems, and it does not find a biblioitem. (Not a fault from TestBuilder
but a database design problem.)
This patch makes a small change in AddReturn to retrieve the itemtype via
biblioitem. It actually is a shorter road than items->biblio->biblioitems.
Note: I do not test the Biblioitems->find call, since we already checked
the GetItem call before and we have a foreign key constraint.
I did not call $item->effective_itemtype since we still use GetItem; this
could be done later.
Adjusted Circulation/Returns.t too: If we add an item with TestBuilder and
we called AddBiblio before, we should link biblioitemnumber as well.
Test plan:
[1] Do not apply this patch yet.
[2] Set item-level_itypes to biblio record.
[3] Run t/db_dependent/Koha/Patrons.t. (It should fail.)
[4] Apply this patch.
[5] Run t/db_dependent/Koha/Patrons.t again.
[6] Run t/db_dependent/Circulation/Returns.t
[7] Git grep on AddReturn and run a few other tests calling it.
Note: Bugs 19070/19071 address three tests that call AddReturn too.
[8] In the interface, check in a book.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Note: Bugs 19070 and 19071 are already pushed. The command in comment #4
has all the tests successful.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. ReturnBeforeExpiry is activated
2. useDaysMode is different from "circulation rules only"
3. Set expiry date of a patron to a near date
4. Set a closed day on calendar for this date
5. Do a checkout
Without patch, return date will be patron expiration date
With the patch, return date will be last open day before patron expiration day
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha suffers of big bugs due to its history: When data are deleted, they
are moved to another tables.
For instance issues and old_issues: when a checkin is done, it is moved
to the old_issues table.
That leads to a main problem that is described on
https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
However we tried first to fix the problem (for issues/old_issues) at
code level on bug 18242.
The goal was to prevent data lost.
Data lost may happens in this case:
Check an item out (issue_id = 1)
Check an item in (issue_id = 1)
Restart MySQL (reset auto increment for issue_id to 1)
Check an item out (issue_id = 1)
Check an item in => BOOM, the issue_id is a PK in old_issues and the
move fails.
Before bug 18242 the data were lost, we inserted the value into
old_issues, which fails silently (because of RaiseError set to 0 in
Koha::Database), then delete the row from issues.
That has been fixed using a transaction.
This patch introduced a regression we tried to fix on bug 18651 comment
0, the patron was charged even if the checkin was rejected.
A good way to fix that would have been to LOCK the tables:
1- Start a transaction
2- LOCK the table to make sure nobody will read id and avoid race
conditions
3- Move the content from one table to the other, dealing with ids
4- UNLOCK the table
5- Commit the transaction
But there were problems using LOCK and DBIx::Class (See commit
905572910b - Do no LOCK/UNLOCK the table).
Finally the solution implemented is not acceptable for several reasons:
- batch checkins may fail
- issue_id will always stay out of sync (between issues and old_issues)
See 18651 comment 66.
Since the next stable releases are very soon, and we absolutely need to
fix this problem, I am suggesting to:
1- Execute the move in a transaction to avoid data lost and reject the
checkin if we face IDs dup
=> It will only reject 1 checkin (max is 1 * MySQL restart), no need to
deal with race conditions,
2- Display a warning on the checkin page and link to a
solution/explanation
3- Communicate as much as we can on the proper fix: Update auto
increment values when the DBMS is restarted -
https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
4- Display a warning on the about page for corrupted data (see bug
18931)
5- Write and make available a maintenance script to fix corrupted data
(TODO LATER)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Set 'OpacRenewalBranch' to various settings
2 - Renew an item for a ptron under each setting
3 - Confirm action_log entries reflect the correct branch for each
secnario
4 - prove t/db_dependent/Circulation/issue.t
Signed-off-by: David Kuhn <techservspec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Item does not have a title attribute, it comes from biblio
- There is an additional call to effective_itemtype done on AddReturn,
so we need to catch both warnings
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The subroutine C4::Biblio::GetBiblioFromItemNumber was wrong for several
reasons:
- badly named, we can get biblio info from a barcode
- SELECT * from items, biblio and biblioitems
makes things hard to follow and debug, we never know where do come from
the value we display
- sometimes called only for trivial information such as biblionumber,
author or title
This patchset suggests to replace it with calls to:
- Koha::Items->find for item's info
- $item->biblio for biblio's info
- $item->biblio->biblioitem for biblioitem's info
Test plan:
Item's info should correctly be displayed on the following pages:
- circulation history
- transfer book
- checkin
- waiting holds
QA will check the other changes reading the code, it's trivial
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
$issue is now a Koha::Checkout, not a hashref
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
is_overdue must be called even if there is not dropbox date (!)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are a few calls to GetItemIssue where it's not as easy to make
sure everything will be fine just replacing the calls with a
Koha::Issues->find
- In AddReturn the overdue flag is used (that's why this patch depends
on bug 17689)
- In CanBookBeRenewed, as well as the overdue flag the dates converted
to DateTime were used. It's now our job to convert them when we need
them.
- Same in AddRenewal but we also call _CalculateAndUpdateFine, so we
need to update the variables in this subroutine.
Note that, prior to this patch, AddReturn returned the GetItemIssue
hashref in the $iteminformation. Most of the time this variable is not
used, I have found only 1 place where it's used: circ/returns.pl
TODO: In this script we should call ->is_overdue instead of the
DateTime->compare calls
Test plan:
All the circulation tests must pass (it's how I have caught the specific
cases).
Do some checkins/checkouts/renewal and focus on the due date
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch simply removes the C4::Circulation::GetItemIssue subroutine
Test plan:
At this point, `git grep GetItemIssue` should not return any occurrence
in the codebase
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Circulation::GetItemIssue returned all the issue and item
informations for a given issue. Moveover it also did some date
manipulations. Most of the time this subroutine was called, there
additional information were useless as the caller usually just needed
the basic issue's infos 'from the issue table).
This first patch updates the simple calls, ie. the ones that just need
the issue's infomations.
Test plan:
The following operations should success:
- transfer a book
- create a rule for on-site checkouts and confirm that a patron cannot
check more items out that it's defined in the rule.
- Renew an issue using ILSDI
- Using SIP confirm that you are able to see your issues
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We cannot LOCK the old_issues table here, other tables are accessed and DBIx::Class rename it with "me":
DBD::mysql::st execute failed: Table 'me' was not locked with LOCK
TABLES [for Statement "SELECT `me`.`issue_id`, `me`.`borrowernumber`,
`me`.`itemnumber`, `me`.`date_due`, `me`.`branchcode`,
`me`.`returndate`, `me`.`lastreneweddate`, `me`.`renewals`,
`me`.`auto_renew`, `me`.`auto_renew_error`, `me`.`timestamp`,
`me`.`issuedate`, `me`.`onsite_checkout`, `me`.`note`, `me`.`notedate`
FROM `old_issues` `me` WHERE ( `me`.`issue_id` = ? )" with ParamValues:
0='2'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832.
Consequence: We could have a checkin refused if there is a race, but
this is the simplest and safest way to fix it.
Found this by inserting the same issue_id in old_issues before checkin:
The call to ->search( )->get_column is in scalar context and will
return the number of results, i.e. always 1.
If you have an issue_id 2 in old_issues, it will crash:
DBIx::Class::Storage::DBI::_dbh_execute(): Duplicate entry '2' for key 'PRIMARY'
The fix is fairly simple: Put get_column in list context and pick the first
array entry.
NOTE: Using DBIx's get_column()->max here might look simpler here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Variable $original_issue_id is not used. The id is retrieved later from
$issue when updating accountlines.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
For more info, see:
commit be156d9ad9
Bug 15854: Use a READ and WRITE LOCK on message_queue
and
commit b40456f7dd
Bug 18364: Do not LOCK/UNLOCK tables from tests
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If the "max(issue_id) from old_issue + 1" already exists in issues, the
move fails.
For instance we have
1, 2, 3, 4 in issues
checkin 4
1, 2, 3 in issues (AI=5)
4 in old_issues
Restart mysql => AI is reset to MAX(issue_id) => 4
checkout a new one
1, 2, 3, 4 in issues (AI=5)
4 in old_issues
checkin 4 (will get id 5 in old_issues)
1, 2, 3 in issues (AI=5)
4, 5 in old_issues
=> This works with and without this patch
Now we have
1, 2, 3 in issues (AI=5)
4, 5 in old_issues
Restart mysql => AI is reset to MAX(issue_id) => 4
checkout 2 new ones
1, 2, 3, 4, 5 in issues (AI=7)
4, 5 in old_issues
checkin 4 (4 becomes 6 in old_issues)
1, 2, 3, 5 in issues (AI=6)
4, 5, 6 in old_issues
=> This did not work without with patch
The update of the issue_id was made before the move (so in the issues
table), the PK did not allow it
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
2. If the move fails for whatever reason (see
https://lists.katipo.co.nz/pipermail/koha/2017-May/048045.html for an
example), fines can be charged. It should not
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
1. AddReturn returns a $issue hashref with the old issue_id value
=> At first glance it does not affect anything, but would be good to fix
it for future uses.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If a patron owes more than the OPACFineNoRenewals value, the issue won't
be auto renewed anymore (driven by the new pref OPACFineNoRenewalsBlockAutoRenew).
Test plan:
Note: You will have to manually change data in your DB, make sure you
have access to the sql cli.
1/ Set the OPACFineNoRenewals to 5 (for instance)
2/ Set OPACFineNoRenewalsBlockAutoRenew to block
3/ Check an item out to a patron and mark is as an auto renewal
4/ Make sure the patron does not have any fees or charges.
5/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has been renewed
6/ Create an invoice for this patron with a amount > OPACFineNoRenewals (6
for instance)
7/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has not been renewed.
8/ Set OPACFineNoRenewalsBlockAutoRenew to allow
9/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has been renewed
Sponsored-by: University of the Arts London
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Janet McGowan <janet.mcgowan@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch set the lang parameter when C4::Letters::GetPreparedLetter is
called to generate the notice.
Note that we do not need to pass it if want_librarian is set.
TODO: I do not know what to do with TransferSlip
Sponsored-by: Orex Digital
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds a new circulation rule (no_auto_renewal_after_hard_limit) to block/allow
auto renewals after a given date.
The idea is to stop renewals at a given date. That way the library will have
time to send overdues and get the books back before the students do on holiday.
Test plan:
0/ Execute the update DB entry
1/ Define a rule with no_auto_renewal_after_hard_limit set to tomorrow
2/ Modify the issues.issuedate, to simulate a checkout in the past:
UPDATE issues
SET issuedate = "yyyy-mm-dd hh:mm:ss"
WHERE itemnumber = YOUR_ITEMNUMBER;
with issuedate = 2 days before for instance
3/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has been renewed
4/ Modify the no_auto_renewal_after_hard_limit and set it to yesterday
5/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has not been renewed
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Janet McGowan <janet.mcgowan@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The test in SendCirculationAlert is extended by adding an env var
called KOHA_NO_TABLE_LOCKS. If this var is set to a true value,
the table locking is skipped too.
This is useful when running a test without prove. The variable could be
set in a shell profile.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
From the MySQL doc:
"LOCK TABLES is not transaction-safe and implicitly commits any active transaction before attempting to lock the tables."
If the LOCK/UNLOCK statements are executed from tests, the current transaction will be committed.
To avoid that we need to guess if this code is execute from testsa or not (yes it is a bit hacky)
Better ideas are welcome!
Another fix would have been to revert
commit be156d9ad9
Bug 15854: Use a READ and WRITE LOCK on message_queue
but theorically a race is still possible.
Existing tests seem to be safe, to test this patch you will need new
tests from bug 17964.
Test plan:
prove t/db_dependent/Letters/TemplateToolkit.t
twice, and notice that changes have been comitted.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Silly error here, the $switch_onsite_checkout is not correctly
calculated, it should not only be set to the value of the syspref, but
meet all the conditions.
Test plan:
Set a circ rule with number of on-site checkout = 2 and number of
checkouts = 2.
Switch on both ConsiderOnSiteCheckoutsAsNormalCheckouts and SwitchOnSiteCheckouts
Do a regular checkout
Do another regular checkout
At this point you have reach the maximum number of checkouts allowed.
Not try another one.
=> Without this patch you will not get the warning
=> With this patch you will see it
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The AddRenewal subroutine currently uses the circulation rules for the branch
stored in the Issues table (which is the holding branch) when calculating the new due date.
This patch replaces using the branch from the Issues table with the branch
specified by the HomeOrHoldingBranch syspref.
To test:
1. Set up 2 branches, Branch1 and Branch2
2. Set up a loan rule in Branch1 for DVDs with a 21 day loan period and a
21 day renewal period.
3. Set up a loan rule in Branch2 for DVDs with a 14 day loan period and a
14 day renewal period.
4. Checkout a DVD belonging to Branch1 while logged into Branch2. It will
receive the correct 21 day loan period.
5. Renewing the same DVD while logged into either Branch1 or Branch2
will give a 14 day due date, rather than 21 days.
6. Checkout a DVD belonging to Branch2 while logged into Branch1. It will
receive the correct 14 day loan period.
7. Renewing the same DVD while logged into either Branch1 or Branch2
will give a 21 day due date, rather than 14 days.
8. Apply the patch and repeat steps 4-7. The correct due date should be given
when the item is renewed, regardless of where it is checked out or renewed.
This update removes reassignment of $branch variable.
Signed-off-by: Cédric Vita <cedric.vita@dracenie.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Sounds more appropriate and consistent with existing action logs.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
20/02/17 : added the syspref RenewalLog
24/20/17 : added a test for the syspref Renewal Log
test plan
1 - Chose a Borrower and have him renewing an item
2 - Check the renew logs : they should be empty
3 - Apply patch and set the syspref RenewalLog to 1
4 - Have the Borrower renewing a new item
5 - Check the renew logs : there should be your renew
I called the function logaction, which is in charge of modifying the
logs, within the function which adds a new renewal at the list.
Signed-off-by: Julien Comte <julien.comte@u-psud.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The code was a bit weird and this patch cleans it a bit by renaming
variables and adding a variable.
Sponsored-by: Orex Digital
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
At the moment the default behaviour is not to cumulate the restriction
periods but to apply the longest one.
This patch set creates a new syspref CumulativeRestrictionPeriods. If
on, the behaviour changes and the restriction periods are cumulated: the
days of the second restriction are added to the actual restriction
period.
We could add a new circulation rule instead of a syspref, but I am not
sure it's very useful to have such granularity for this behaviour (can
be changed if needed).
How it works:
Let's take 2 items, A and B.
A is returned with Na days late, and B Nb days late
The grace period is Ng and there is 1 day of suspension charge per day
of overdue
The suspension period is until day D = Na - Ng + Nb - Ng
I would have expected D = Na + Nb - Ng but it's how it worked before
this patch.
Test plan:
Create several overdue for a given patron
Do the checkins and confirm that the period are added if the pref is on.
If the pref is off, you should not get any changes in the existing behaviour.
Sponsored-by: Orex Digital
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To make sure we will not never get a race conditions for these kinds of
notices, we need to add a LOCK on the message_queue table.
This does not smell the best way to do that, but I faced deadlock issues
when I tried to use "UPDATE FOR"
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.htmlhttps://dev.mysql.com/doc/refman/5.7/en/lock-tables.htmlhttps://dev.mysql.com/doc/refman/5.7/en/commit.html
To test this patch, or another solution, you need to apply manually this
change:
my $message = C4::Message->find_last_message($borrower, $type, $mtt);
unless ( $message ) {
+ sleep(1);
C4::Message->enqueue($letter, $borrower, $mtt);
} else {
And repeat the test plan from first patch.
Do not forget to truncate the message_queue table.
Followed test plans, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
There is an obvious race condition when CHECKIN and RENEWAL are
generated from circulation.pl calling svc/renew or svc/checkin in AJAX.
The 2 first queries will try to get the id of the last message
(find_last_message) and if it does not exist, they will insert it.
Theorically that could be lead to have several "digest" messages for a
given patron.
I did not recreate more than 2 messages, from the third one at least one
of the two firsts existed in the DB already.
This patch just simplifies the code to make the SELECT and INSERT or
UPDATE closer and limit the race condition possibilities.
Test plan:
0. Set RenewalSendNotice and circ rules to have a lot of renewals available
1. Use batch checkouts (or one by one) to check out several items to a
patron
2. Empty message_queue (at least of this patron)
3. Renew them all at once ("select all" link, "renew or check in"
button)
4. Check the message_queue
Without this patch you have lot of chances to faced a race condition and
get at least 2 messages for the same patron. This is not expected, we
expect 1 digest with all the messages.
With this patch apply you have lot of chances not to face it, but it's
not 100% safe as we do not use a mechanism to lock the table at the DBMS
level.
Tested both patches together, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The table old_issues has a primary key defined on the issue_id column.
This issue_id comes from the issues table when an item is checked in.
In some case the value of issue_id already exists in the table
Basically this happens when an item is returned and mysqld is restarted:
The auto increment value for issues.issue_id will be reset to
MAX(issue_id)+1 (which is the value of the last entry of old_issues).
See also the description of bug 18003 for more informations.
In this solution the change is done at code level instead of DB
structure: If old_issues.issue_id already exists before moving from
the issues table, the issue_id is updated (not on cascade for
accountlines.issue_id, should it?) before the move.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Charges should not include elements less than a penny/cent
they are not displayed but can be saved to the database
causing "odd" behaviour down the line
Make the routine round the resultant charge to nearest cent,
so consistent values are returned.
Removed the one case where it was rounded post call.
Although the main danger is values generated by the discount
calculation apply the rounding to all returned charges in case
the item charge is defined using the 3rd or 4th decimal
places.
NOTE: prove -v t/db_dependent/Circulation.t triggers the change.
Though, all the returned amounts are 0.00 only.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Members::GetBorrowersWithIssuesHistoryOlderThan subroutine is supposed
to return the patrons with an issue history older than a given date.
It would make more sense to return a list of Koha::Patrons.
On the way, the code from AnonymiseIssueHistory will be moved as well to
anonymise_issue_history.
Note that these 2 subroutines are strongly linked: one is used to know the
number of patrons we will anonymise the history, the other one is used to
anonymise the issues history. The problem is that the first one is not used to
do the action, but only for displayed purpose.
In some cases, these 2 values can differ, which could be confusing.
Case 1:
The logged in librarian is not superlibrarian and IndependentBranches is set:
if 2+ patrons from different libraries match the date parameter, the interface
will display "Checkout history for 2 patrons will be anonymized", when actually
only 1 will be.
Case 2:
If 2+ patrons match the date parameter but one of them has his privacy set to
forever (privacy=0), the same issue will appear.
This patch moves the code from C4::Members::GetBorrowersWithIssuesHistoryOlderThan
to Koha::Patrons->search_patrons_to_anonymise and from
C4::Circulation::AnonymiseIssueHistory to
Koha::Patrons->anonymise_issue_history
Test plan:
1/ Confirm the 2 issues and make sure they are fixed using the Batch
patron anonymization tool (tools/cleanborrowers.pl)
2/ At the OPAC, use the 'Immediate deletion' button to delete all your
reading history (regardless the setting of the privacy rule)
3/ Use the cronjob script (misc/cronjobs/batch_anonymise.pl) to
anonymise patrons.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
when a item match a borrower, there is no point in checking the
other borrowers
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When a loan period is shortened due to using decreaseLoanHighHolds* the time is
always set to the current time in X days, even if the original loan period is
given in days and not in hours.
It should default to 23:59 as is normal for loan periods given in days.
As original due date time defaults to 23:59 when given in days, this patch
modifies the hours and minutes of shortened due date to be equal to original due
date.
To test:
1. prove t/db_dependent/DecreaseLoanHighHolds.t
Signed-off-by: Grace McKenzie <grace.mcky@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We should require a circulation rule to allow checkouts and reject them
if no rules are defined.
Test plan:
- Delete all issuing rules
- Check an item out
=> Without this patch the checkout is allowed
=> With this patch applied it is rejected
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* C4/Circulation.pm (GetTransfers, GetTransfersFromTo): Also return
branchtransfer_id in return columns.
* installer/data/mysql/atomicupdate/14187.perl: New file.
* installer/data/mysql/kohastructure.sql: Modify branchtransfers structure.
* t/db_dependent/Circulation/transfers.t: Update tests to expect
branchtransfer_id.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Test plan successful on all steps.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch: Remove Schema changes from this patch
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Ready for an archaeology course?
C4::Circulation::GetItemIssues is only used once, from
catalogue/issuehistory.pl
This call has been added by
commit 95d6452462
Adding some more information on issuehistory.
which says "Adding itemnumber to issuehistory.pl API so that one could search
for issuehistory of a specific item."
So it added the ability to see the item issue history but did not
provide a way to access it via the interface.
It's ok so far but this subroutine is broken since
commit aa114f5349
Bug 5549 : Only use DateTime for issues table
because of this change:
- my $today = C4::Dates->today('iso');
+ my $today = DateTime->now( time_zome => C4::Context->tz);
I let you catch the typo ;)
And since this commit the subroutine explodes with "The following
parameter was passed in the call to DateTime::from_epoch but was not
listed in the validation options: time_zome"
Since it has never been raised by someone and that the feature is
hidden, I'd recommend to simply remove it.
Note that the "Checked out from" column would have been wrong even if we
fixed all the previous issue.
Test plan:
Just dig into the code and confirm what this commit message tells
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Looks fine for me.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
For no discernable reason, when AddIssue calls AddRenewal, it passes the
branchcode generated from _GetCircControlBranch. Assume
_GetCircControlBranch is set to return items.homebranch. So:
1) If an item owned by LibraryA is checked out at LibraryB, the
statistic line branchcode will be LibraryB
2) If an item is renewed via the ajax datatables renewal function, the
statistic line branchcode will be LibraryB the
3) If an item is renewed via scanning the item into the checkout again,
statistic line branchcode will be *LibraryA*
This is clearly improper behavior. The renewal is taking place at
LibraryB, so the branchcode passed to AddRenewal should be LibraryB,
the logged in library. This also jives with the documentation for
the subroutine.
Test Plan:
1) Set CircControl to "the library the item is from" aka ( ItemHomeLibrary )
2) Set HomeOrHoldingBranch to 'The library the items is from" ( aka homebranch )
3) Create item with homebranch of LibraryA and holdingbranch of LibraryB
4) Set the logged in library to LibraryB
4) Check the item out to a patron at LibraryB
5) Note the statistics line has a branchcode of LibraryB
6) Check the item out again to trigger a renewal, renew the item
7) Note the statistic line has a branchcode of LibraryA!
8) Apply this patch
9) Repeat step 6
10) Note the statistics line has a branchcode of LibraryB!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Kuhn <kuhn@monterey.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Circulation::GetIssues subroutine is only called once and can be
replaced with a call to Koha::Isues->search with a join on items.
Test plan:
- Apply first patch and make sure the tests pass
- Apply second patch and make sure the tests still pass
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
All the values different from the ones GetMember returned has been
managed outside of GetMemberDetails.
It looks safe to replace all the occurrences of GetMemberDetails with
GetMember.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Same as authflags, a flags key is set containing all the patron flags.
It is only used in a few places and it's better to call
C4::Members::patronflags when we need it.
Test plan:
Look at the diff and confirm that the change make sense
Use git grep to confirm we do not use the flags somewhere else.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a
borrower has an item checked out that has many items {30+} AND many
holds {70+) on it, loading the checkouts table for this borrower takes
FOREVER to load. The load time takes forever, because of the
factoring that happens to determine if an item is truly
available for renewal.
This patch swaps the use of GetMemberDetails for GetMember
and reorders the subroutine calls to check each items' renewability
from fastest to slowest.
In a test case, the results of pre patch were:
Start of loop: 2016-08-24T11:05:14
End of loop: 2016-08-24T11:05:29
Resulting in 15 seconds being spent in the loop
Post patch results were:
Start of loop: 2016-08-24T11:08:43
End of loop: 2016-08-24T11:08:48
Resulting in only 5 seconds being spent in the loop!
Test Plan:
1) Apply this patch
2) Note there are no changes in functionality for the renewals column of
the patron checkouts table.
If you wish to go further and test the performance benefit:
1) Create a record with 50 items and 100 holds ( 50 waiting, 50 unfilled )
2) Check out one of the waiting holds to a patron
3) Time the amount of time it takes for the checkouts table to load
4) Apply this patch
5) Repeat step 3, you should see an improvement in load time
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an issue marked as auto_renew is renewed manually, we want to display
the latest auto renew date possible.
Test plan:
1/ Define circ rules as in the previous patch.
2/ Check a item out, mark it as an auto renewal
3/ Back date the issuedate and make sure it will be too late to renew it
4/ Use the Circulation > renew page (circ/renew.pl) to manually renew
this issue.
You should get a warning "You barcode has been scheduled for automatic renewal
and cannot be renewed anymore since DATE."
If the pref AllowRenewalLimitOverride is set, you will be allowed to
renew it anyway.
Sponsored-by: University of the Arts London
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds a new circulation rule (no_auto_renewal_after) to block/allow
auto renewals after a given delay.
For instance, if the issue date is 10 days before today, and
no_auto_renewal_after is set to 10, tomorrow the issue won't be auto
renewed.
Test plan:
0/ Execute the update DB entry
Note: You will have to manually change data in your DB, make sure you
have access to the sql cli.
1/ Define a rule with no_auto_renewal_after (10 for instance) and
norenewalbefore (5 for instance).
(This new rule will behave the same as norenewalbefore: the unit depends
on the lengthunit value).
The automatic renewals will be done from 5 to 10 days ahead.
2/ Modify the issues.issuedate, to simulate a checkout in the past:
UPDATE issues
SET issuedate = "yyyy-mm-dd hh:mm:ss"
WHERE itemnumber = YOUR_ITEMNUMBER;
with issuedate = 2 days before for instance
3/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has not been renewed (too soon)
4/ Repeat step 2 with a due date set as 11 days before
5/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has not been renewed (too late)
6/ Repeat step 2 with a due date set as 7 days before
7/ Execute the automatic renewals cronjob script (misc/cronjobs/automatic_renewals.pl)
Confirm that the issue has been renewed (issues.renewals has been
incremented and date_due has been updated according your circ rules).
Sponsored-by: University of the Arts London
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Jonathan Druart
Martin Renvoize
Kyle M Hall
Nick Clemens
Andrew Isherwood
Christopher Brannon
Jesse Weaver
Tomas Cohen Arazi
Fridolin Somers
Caroline Cyr La Rose
Josef Moravec
Alex Buckley
Marcel de Rooy
Kyle M Hall
Kyle M Hall
David Bourgault
Lari Taskula
Mark Tompsett
Colin Campbell
Alex Arnaud
Sophie Meynieux
Chris Cormack
phette23
David Kuhn
Baptiste Wojtkowski
Francesco Rivetti
Olli-Antti Kivilahti
Brendan A Gallagher