When creating a circ rule, we can set overduefinescap to blank or 0 and no cap is enforced. If we edit that rule, the blank/0 is converted to "0.00" which perl considers true, thus zero-ing out any calculated fine.
Considering we've always ignored an overdue fines cap of 0, we should also ignore 0.00. However, perl is evaluating it as a string which makes it true instead of false as 0 is.
Test Plan:
1) Apply the first patch ( unit tests )
2) prove t/db_dependent/Circulation/CalcFine.t
3) Note the test fails
4) Apply the second patch as well
5) prove t/db_dependent/Circulation/CalcFine.t
6) Note the test passes
Test Plan 2:
1) Create an all/all/all rule with an overduefinescap of 0.00, with a
daily fine. Enable CalculateFinesOnReturn
2) Backdate a checkout so it is overdue
3) Return this item, note the lack of a fine
4) Apply this patch set
5) Backdate a checkout and return it again
6) Note the fine is generated!
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The TooMany() function and fine calculation functions were incorrectly
hard coded to use homebranch for fetching the circulation rules. Those
ignored completely the syspref HomeOrHoldingBranch where the user
might have set it to holdingbranch and therefore the fines and whether
patron has too many checkouts (TooMany()) were counted using the
unintended branch's rules. This problem only arises in the cases where
there are branch specific circulation rules defined.
Test plan:
1. Make sure following tests pass:
$ prove t/db_dependent/Circulation/_CalculateAndUpdateFine.t
$ prove t/db_dependent/Circulation/TooMany.t
Test plan for fines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with home and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl /usr/share/koha/bin/cronjobs/fines.pl
6. Notice that fines have popped up now to the patron incorrectly
7. Apply patch
8. Pay fines, Check-in the item and check it out again
9. Run perl /usr/share/koha/bin/cronjobs/fines.pl
10. Notice that fine is now 0. This means that the branch
B (holdingbranch of the checked-out item) specific rule is used.
Test plan for staticfines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with homebranch A and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice that now there is inccorectly fines
6. Apply patch
7. Pay fines, Check-in the item and check it out again
8. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice the fines are now not generated
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the letter has been removed, fall back to itemnumber/due date. (Title is
no longer fetched.) We may assume that the notice is present.
Note: The option to 'protect' a notice may need some more thought. Perhaps
it needs to be an attribute on itself.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested by deleting notice, running fines again.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be great if we could customize what information was added to the "Description of charges" field when a fine was made so data could be stored even when the item is deleted.
Test Plan:
1) Create an overdue checkout that will get a fine
2) Run fines.pl
3) Note the description for the fine
4) Delete the fine from the database
5) Apply this patch
6) Run updatedatabase.pl
7) Restart all the things!
8) Run fines.pl
9) Note the description of the fine is unchanged
10) Delete the fine again
11) Browse to Slips & Notices
12) Edit the new notice OVERDUE_FINE_DESC
You will have access to the objects checkout, item, and borrower
13) Run fines.pl
14) Note your new description was used
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Argument "" isn't numeric in multiplication (*) at /usr/share/koha/lib/C4/Overdues.pm
To test:
* Create a issuing rule where fine is empty, but a fine interval is set.
Fine amount: empty
To do this, remove the 0 displayed in the input field before saving.
Fine charging interval: 5 or any other numeric value
When to charge: Start of interval
Fine grace period: 0
* Check out an item with the due date yester (use specify due date)
* Run misc/cronjobs/fines.pl -v
* You should see above warn in the output
* Apply patch
* Rerun fines.pl, there should be no warn.
* Run:
t/db_dependent/Circulation/CalcFine.t
t/db_dependent/Fines.t
t/db_dependent/Circulation.t
t/db_dependent/Overdues.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the different ->recalls accessors implemented on this
bug be more standard. This means:
- They don't do special things like default sorting or stripping out
special parameters. That's all left to the caller and the methods are
clean: they just return the related objects
- Useful filtering methods for Koha::Recalls resultsets are added. The
only used one (in the end) was ->filter_by_current. It seems like a
better approach, because it gives devs more control on how they want
to chain things, and there's a single place in which to maintain the
criteria of what is 'current' or 'finished'. This clearly makes the
'old' column obsolete IMHO, at least in the use cases I found. This is
covered by tests as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the status attribute an ENUM, setting the default value
as 'requested' as well. The chosen names are easier to read than single
letters. Also, renamed F into fulfilled (this impacts methods names as
well). This is because 'finished' or 'completed' is more a synonym for
old => 1...
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The fines cron job uses Getoverdues to pass issue info to CalcFine.
It took me a while to realize that the overdue hash does not contain
a biblionumber. When testing CalcFine, we pass an item hash that
does include one.
So what happened? $item->{biblionumber} is undefined when it comes from
Getoverdues and no recall overdue fine is calculated, only a regular one.
Simple fix (without any impact): Add a biblionumber to Getoverdues.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with fines.pl: recall fine applied now.
Ran some Circulation and Overdues unit tests.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
- misc/cronjobs/recalls/expire_recalls.pl
- misc/cronjobs/recalls/overdue_recalls.pl
- tests for overdue fines in t/db_dependent/Circulation/CalcFine.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.
This patch only removes the obvious places, not the tricky ones.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 28572: Replace missing occurrence in misc/admin/koha-preferences
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Historical OVERDUE fines may not have an issue_id - this causes
flooding of the logs when calling update fine
Trivial change, reading the code should be enough, but test plan below
To test:
1 - Create some fines without an issue_id
- Either checkout an old version of Koha and add manually or
- Checkout some items (backdated) to a patron, run fines.pl then
UPDATE accountlines SET issue_id = NULL;
2 - Checkout a backdated item with fines in the circ rule to the same patron
3 - Run fines.pl
4 - Note the errors
5 - Apply patch
6 - Repeat and note no errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We cannot compare calculated values directly as those calculations may
have introduced floating point differences. We have the
Koha::Number::Price->round function to consistently round the floating
point number to a decimal with 2 points precission for comparison.
Test plan
1/ Set a circ rule to have a .15 per day fine and enable finesMode
syspref.
2/ Issue an item of this type to a borrower (making it 12 days overdue
by setting the due date to 12 days in the past)
3/ Run the fines job:
4/ Pay the fine for the patron
5/ Check in the item
6/ Note that the patron does not have an 'Overpayment refund' of $0.00
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Bug 27079: (QA follow-up) Round both sides for clarity
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If maxFine is set, we total the patrons outstanding fines when making an adjustment, however, we neglect to count the amount of a currently updating fine when doing so.
To test:
1 - Set maxFine to 5
2 - Create an overdue amount of 4.99 for a patron
3 - Set an itemtype to have a fine of $.10 per day
4 - Checkout an item of that type to a patron and backdate the due date so it is overdue
5 - Run fines.pl with -v
6 - Note the fine is reduced from $.10 (or a multiple) to .01
7 - Run it again, a second cent is added
8 - Repeat and note it keeps happening until the amount of the fine is reached, exceeding the maxFine setting
9 - Apply patch
10 - Note the fine is now reduced to 0 and nothing is added to account
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>
Test plan:
0) Apply patch
1) try to run affected scripts and ensure the amounts are corectly
calculated for different patron categories:
installer/data/mysql/fix_unclosed_nonaccruing_fines_bug17135.pl
misc/cronjobs/fines.pl
misc/cronjobs/staticfines.pl
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.
To prevent other issues related to this syntax this patch suggests to
replace them all in one go.
Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The chargename rule is not used anywhere in the code
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>
The `maxFine` system preference actually refers to the amount of
outsanding debt (in fines) a patron may have at a given time. This patch
corrects the functionality of UpdateFine such that it properly respects
that counter given the payment of accruing fines scenario.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We should increment an existing fine even if it has been fully paid off
whilst it is still incrementing and not create a new fine.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
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>
* 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>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.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>
We changed the way we classify fines with bug 22521 but missed one
instance.
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>
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: 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>
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>
This patch intelligently renames the account_offset types for updateing
fines from `Fine Update` to `fine_increment` and `fine_decrement`
depending on the sign of the calculated difference of the adjustment.
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>
Set to use Koha::Account->add_debit and Koha::Account::Line->adjust
Known Side Effect: The format of the FinesLog, if enabled, is changed
after this patch. Prior to this patch the $actionname was left undefined
and the $infos field contained the string:
`"due=".$due." amount=".$amount." itemnumber=".$itemnum`
After this patch, the logs are more consistent with other FINES logs,
with an $actionname of 'CREATE' or 'UPDATE' and the $infos field
containing a Dumper of fine data.
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>
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>
When circ rules are set to cap at item replacement cost, calcfine only
checks the price in the item record, not the default replacement cost by
item type.
Note: We do not take '0' into account, what if you do not want to set
a replacement cost for an item? It is how it is done in chargelostitem
so keeping the existing behaviour, but that may be considered as a bug (?)
Test plan:
- Set useDefaultReplacementCost to use
- Set a default replacement cost for a given item type
- Create an item of that type with a replacementcost=0
- Create a circ rule for that item type that accrues fines but caps at
replacement cost
- check the item out, forcing a due date in the past
- check that item in
=> Fines should have been generated
Signed-off-by: Caroline Cyr La rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It appears that has never worked.
Could someone confirm?
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>
This patch drops the notifys table and its related code in C4::Overdues.
A second patch should remove the 2 columns notify_id and notify_level
from the accountlines table.
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>
