Since bug 29486, misc/maintenance/search_for_data_inconsistencies.pl search for biblio.biblionumber in MARC record with $record->subfield().
This fails when field is a control field (< 10).
Idem for biblioitems.biblioitemnumber
Test plan :
1.0) On a UNIMARC database (biblio.biblionumber is on 001)
1.1) Run misc/maintenance/search_for_data_inconsistencies.pl
=> Without patch you get error : Control fields (generally, just tags below 010) do not have subfields, use data()
=> With patch no error
2.0) On a MARC21 database (biblio.biblionumber is on 999c)
2.1) Run misc/maintenance/search_for_data_inconsistencies.pl
=> Check you see no error
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In search_for_data_inconsistencies.pl, the test for authorized values is a list in one line :
* The Framework *VR* is using the authorised value's category *LOC*, but the following items.location do not have a value defined ({itemnumber => value }):
{94 => AV} {95 => AV} {96 => AV} {97 => AV} {98 => AV} {99 => AV} {100 => AV} {101 => AV} {102 => AV} {103 => AV}
It would be more clear with new lines, especially for scripts (grep, awk ...) :
* The Framework *VR* is using the authorised value's category *LOC*, but the following items.location do not have a value defined ({itemnumber => value }):
{94 => AV}
{95 => AV}
{96 => AV}
{97 => AV}
{98 => AV}
{99 => AV}
{100 => AV}
{101 => AV}
{102 => AV}
{103 => AV}
Test plan :
1) In koha-testing-docker
2) Delete in authorized values LOC the value AV
3) Run misc/maintenance/search_for_data_inconsistencies.pl
=> You see the new line in result
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In search_for_data_inconsistencies.pl when there are several inconsistencies on same framework, the second output of items contains the first one.
Looks like it is since Bug 21466
Test plan using koha-testing-docker :
1) Create 2 inconsistencies on the same item via SQL :
update items set itemlost = 9 where itemnumber=900;
update items set notforloan = 8 where itemnumber=900;
2) Without patch
3) Run ./misc/maintenance/search_for_data_inconsistencies.pl
=> You see duplicate output :
== Wrong values linked to authorised values ==
* The Framework *BKS* is using the authorised value's category *NOT_LOAN*, but the following items.notforloan do not have a value defined ({itemnumber => value }):
{900 => 8}
* The Framework *BKS* is using the authorised value's category *LOST*, but the following items.itemlost do not have a value defined ({itemnumber => value }):
{900 => 8} {900 => 9}
4) Apply patch
5) Run ./misc/maintenance/search_for_data_inconsistencies.pl
=> Fixed :D
== Wrong values linked to authorised values ==
* The Framework *BKS* is using the authorised value's category *LOST*, but the following items.itemlost do not have a value defined ({itemnumber => value }):
{900 => 9}
* The Framework *BKS* is using the authorised value's category *NOT_LOAN*, but the following items.notforloan do not have a value defined ({itemnumber => value }):
{900 => 8}
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If an AV is linked to a MARC field mapped with a biblio column, the
search_for_data_inconsistencies.pl script might explode with
The method Koha::Biblioitem->title is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Object.pm line 875
Koha::Object::AUTOLOAD('Koha::Biblioitem=HASH(0x556b67fa7168)') called at misc/maintenance/search_for_data_inconsistencies.pl line 246
Test plan:
For a given framework, pick a biblio using it
Link 245$a with an authorised value category
Run the script
=> Notice that with this script applied you will see the warning
=> Without this patch you got the error
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Avoid warns 'Use of uninitialized value in sprintf' by using
'0' if lower age is undefined
'unlimited' if upper are is undefined
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Also added category limits in message, for example (12-18)
Check patron :
- with no date of birth
- with invalid age in category having age required
- with invalid age in category having upper age limit
- with invalid age in category having age required and upper age limit
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a suggestion for rephrasing the message slightly:
Before:
* Patron borrowernumber=15 in category 'J' has invalid age '56'
After:
* Patron borrowernumber=37 has an invalid age of 37 for their category 'K'
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Patron categories may have age limits.
Add to script misc/maintenance/search_for_data_inconsistencies.pl the list of patrons which age is invalid regarding there category.
Test plan :
1) Create an adult patron category limited to 18-99 years
2) Create a patron in the category
3) Edit in database its date of birth so that he is 17 years old
4) Run misc/maintenance/search_for_data_inconsistencies.pl
=> You see the patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the MARC record does not contain the correct biblionumber of
biblioitemnumber, the script will display the following warning:
== Bibliographic records have MARCXML without biblionumber or biblioitemnumber ==
* Biblionumber 4242 has '1' in 999$c
* Biblionumber 4242 has biblioitemnumber '4242' but should be '1' in 999$d
=> The bibliographic records must have the biblionumber and biblioitemnumber in MARCXML
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The errors reported seem to be caused by authorised values mapped to MARC fields
but not mapped to a koha field.
We should additionally make sure to check the Default framework
Also, adding comment to indicate we only check records with items, because we do
TO test:
1 - In a framework that is not the default map a MARC field to an authorised value, but not a koha field
2 - In SQL, force the kohafield to NULL for the mapping you just make
UPDATE marc_subfield_structure SET kohafield = NULL WHERE frameworkcode='BKS' and authorised_value='HINGS_AS'
3 - perl misc/maintenance/search_for_data_inconsistencies.pl
4 - get the following errors:
Use of uninitialized value $tmp_kohafield in pattern match (m//) at /kohadevbox/koha/misc/maintenance/search_for_data_inconsistencies.pl line 151.
Use of uninitialized value $tmp_kohafield in substitution (s///) at /kohadevbox/koha/misc/maintenance/search_for_data_inconsistencies.pl line 154.
Can't call method "get_column" on an undefined value at /kohadevbox/koha/misc/maintenance/search_for_data_inconsistencies.pl line 157.
5 - Apply patch
6 - Repeat
7 - No more errors
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 23871 added check for 'title exists' to `search_for_data_inconsistencies.pl`.
There is a typo in DBIx query to create or : hashref instead of arrayref.
Test plan :
1) Change title of biblio record XXX in SQL :
UPDATE biblio SET title = '' WHERE biblionumber=XXX
2) Change title of biblio record YYY in SQL :
UPDATE biblio SET title = NULL WHERE biblionumber=YYY
3) Run misc/maintenance/search_for_data_inconsistencies.pl
4) Check you see both records
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - sudo koha-mysql kohadev
2 - UPDATE biblioitems SET itemtype = NULL where biblionumber = 1
3 - UPDATE items SET itype = NULL where biblionumber = 1
4 - perl misc/maintenance/search_for_data_inconsistencies.pl
5 - Notice warnings
6 - Apply patch
7 - Undefined itemtype on bibliolevel is now warned
7 - Test also with itype=""
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In biblio records, a field must be linked to biblio.title.
200$a in UNIMARC, 100$a MARC21 (and other).
If this field is undefined, some pages like checkouts table can fail.
Test plan :
1) Remove biblio title in SQL :
UPDATE biblio SET title='' WHERE biblionumber=XXX
2) Run misc/maintenance/search_for_data_inconsistencies.pl
3) You see the record as an inconsistency
4) Reset a title
UPDATE biblio SET title='50 shades of Grey' WHERE biblionumber=XXX
5) Run misc/maintenance/search_for_data_inconsistencies.pl
6) Record is no longer an inconsistency
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There was a major (and silly) issue in the previous version, only one AV
was kept as we erased the hash value at the end of each iteration:
$invalid_locations_per_framework->{$framework->frameworkcode } =
{ items => $items, av_category => $mss->authorised_value, kohafield => $kohafield };
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I do not think we should have the same trick as the intranet, and
display a message. This should be enough.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This may be quite long for big catalogue, but I think it is a good one
to have.
Test plan:
Same as first patch, then execute search_for_data_inconsistencies.pl
Notice the error.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch change Koha::Cron to be a more generic Koha::Script class and
update all commanline driven scripts 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>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
search_for_data_inconsistencies.pl will now display errors if:
1.item-level_itypes is set to "specific item" and items.itype is not set
or not set to an item type defined in the system (itemtypes.itemtype)
2.item-level_itypes is set to "biblio record" and biblioitems.itemtype is not set
or not set to an item type defined in the system (itemtypes.itemtype)
Test plan:
Use the script and the different possible combinations to display the
errors
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a new check in
misc/maintenance/search_for_data_inconsistencies.pl to search for not
defined authority codes.
Test plan:
Set some auth_header.authtypecode to not defined authority codes in Koha
(UPDATE auth_header SET authtypecode="XXX" WHERE authid=42;)
Then run `misc/maintenance/search_for_data_inconsistencies.pl`
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: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
From bug 5789: scripts can fail if items.homebranch and/or
items.holdingbranch is not defined
This script will help people catching these migration issues.
Test plan:
Update your items table to set some homebranch or holdingbranch to NULL
Run this script
It will display the different items with not defined values in these
fields.
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>
