CalcFine returned values that mismatched expectations in fines.pl.
fines.pl refactored: added debugging, prevent needless recreation of
Calendar objects by storing them in hash by branch.
Still outstanding problems with fines, including the output of a field
that has no other references in Koha (so is always undef) and the
incorrect description of FinesMode.
Calendar exported "new" erroneously. I also cleaned up the queries to
avoid needlessly compiling additional statement handles.
Please test and consider application to 3.0 maintenance.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
SQL fix to properly ensure that if an item is on
the hold shelf, it will not be used for request
targeting, which applies only to items that are
not already on the hold shelf.
Prior to this fix, when checking out an item on the
hold shelf that fills patron A's hold request, it
was possible for that request to not be marked as
filled if another patron had an item-level request
on the item; the second patron's request was
incorrectly targeted by that item.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This batch job now automatically populates the
holds request targeting table hold_fill_targets.
This patch is essentially a revamp of the job,
and includes fixes for the following bugs:
2281 (holds queue report including unavailable items)
2331 (holds queue report not working with item-level
holds)
2332 (holds queue script should attempt to fill
many requests as possible).
Several functions in this batch job are candidates
for being moved to C4::Reserves:
GetBibsWithPendingHoldRequests()
GetPendingHoldRequestsForBib()
GetItemsAvailableToFillHoldRequestsForBib()
MapItemsToHoldRequests()
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The problem is that we do not ensure that the issues table has valid
borrowernumber in each line. This is exacerbated by Getoverdues()
returning data sorted BY borrowernumber. So one NULL borrowernumber
in issues prevented ALL fines from being assessed. The actual error
from fines.pl cron log is:
No branchcode argument to new. Should be C4::Calendar->new(branchcode => $branchcode)
at /home/user/kohaclone/misc/cronjobs/fines.pl line 98
This patch deals only with getting fines to avoid crashing. It does
not fix the underlying data integrity problem.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
This patch refound all the script which fix all records without any biblionumber.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
This has bearing on bugs 2905, 2665, 2514 and other "wide character" crashes
related to diacritics and Unicode. This should help open the door for reliable
input of diacriticals via acquisitions.
MARC21_utf8_flag_fix.pl diagnoses and fixes existing problems with MARC data
affected by the bug.
Adding SetMarcUnicodeFlag to TransformKohaToMarc prevents the bug from corrupting
further data.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Acquisitions process seems to be adding records with incorrect
representation of the MARC encoding in leader/09. It should be
'a' meaning UTF-8, for all Koha's internalized records, but in
many cases it appears blank (for MARC-8). This script diagnoses
and repairs the value in the leader, depending on runtime options.
The symptom of this problem is that high-value UNICODE characters
in the record will cause Koha to crash whenever it tries to parse
the MARCXML, giving a "Wide character" fatal. While we work on
fixing the input, this script will fix the existing data.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Joe Atzberger
Galen Charlton
Chris Cormack
Henri-Damien LAURENT
Frédéric Demians
Nahuel ANGELINETTI