June 2022 - Koha-bugs - lists.koha-community.org

[Bug 30996] New: ModBiblio breaks MARC::File::XML
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30996 Bug ID: 30996 Summary: ModBiblio breaks MARC::File::XML Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org This is a weird issue. It could very well be something particular to my setup, but I am at a loss as to what it might be, so here goes... This is happening on a regular Koha 20.11.13.000, installed with the Debian packages, on Ubuntu 20.04.3. I have a script that downloads records from the Swedish national library Libris, does some checking and some massaging, and then imports the records into Koha with either AddBiblio or ModBiblio. The script can be found here: https://github.com/Libriotech/ftp2koha About a month ago messages like these started to show up in the logs for some of the imported records: Wide character in warn at /usr/share/perl5/MARC/Charset.pm line 384. no mapping found at position 1 in ビードマルク, マッティン, at /usr/share/perl5/MARC/Charset.pm line 384. Records that produce this error show broken chars, with chars like äöå shown as a diamond with a question mark in it. The records look ok before they are imported, and tools like yax-marcdump does not show errors for them. Position 9 in the leader is "a", to indicate the records are UTF8. Three records in one file are attached. I have tried to reduce the problem down to a minimal case, and come up with this script: -------------------------------------------------------------------- #!/usr/bin/perl use Modern::Perl; use C4::Biblio qw( ModBiblio ); use MARC::File::XML ( BinaryEncoding => 'utf8', RecordFormat => 'MARC21' ); my $records = MARC::File::XML->in( 'export_2022_06_16_1120_orig.marcxml' ); # Start transaction my $schema = Koha::Database->new()->schema(); $schema->storage->txn_begin(); my %map = ( 'p4rdqd4nm9f4dhv3' => 349078, 'jzzcjbt4gt0f0z8w' => 348789, '1fmgws1lzrk71k2t' => 349079, ); RECORD: while ( my $record = $records->next() ) { say $record->leader; say "=========^=============="; $record->encoding( 'UTF-8' ); my $id = $record->field( '001' )->data; my $biblionumber = $map{ $id }; if ( $ARGV[0] > 1 ) { say ModBiblio( $record, $biblionumber, '' ); } } # End transaction $schema->storage->txn_rollback(); -------------------------------------------------------------------- The results of running that script are different depending on if ModBiblio gets called or not. With "0" as the argument it does not get called and everything looks ok. Leader pos 9 is "a": $ sudo koha-shell -c "perl -MCarp::Always test_minimal.pl 0" norrbott cim a 7i 4500 =========^============== ngm a 7i 4500 =========^============== cim a 7i 4500 =========^============== With "2" as argument, ModBiblio does get called, and there are errors related to encoding (from the call to $records->next()), from the second and third record. Notice also that leader pos 9 for record number two and three is now empty! So when ModBiblio is triggered, the UTF8 indicator is suddenly gone, and as far as I can see, this is what is causing the encoding errors: $ sudo koha-shell -c "perl -MCarp::Always test_minimal.pl 2" instancename cim a 7i 4500 =========^============== 1 Wide character in warn at /usr/share/perl5/Carp/Always.pm line 18. no mapping found at position 1 in ビードマルク, マッティン, at /usr/share/perl5/MARC/Charset.pm line 384. MARC::Charset::utf8_to_marc8("\x{30d2}\x{3099}\x{30fc}\x{30c8}\x{3099}\x{30de}\x{30eb}\x{30af}, \x{30de}\x{30c3}\x{30c6}\x{30a3}\x{30f3},") called at /usr/share/perl5/MARC/File/XML.pm line 480 MARC::File::XML::decode(MARC::File::XML=HASH(0x56070fb9c278), "<record><leader> ngm a 7i 4500</leader><controlfiel"...) called at /usr/share/perl5/MARC/File.pm line 110 MARC::File::next(MARC::File::XML=HASH(0x56070fb9c278)) called at test_minimal.pl line 19 ngm 7i 4500 =========^============== Use of uninitialized value in join or string at /usr/share/perl5/MARC/Field.pm line 696. MARC::Field::as_usmarc(MARC::Field=HASH(0x560718749560)) called at /usr/share/perl5/MARC/File/USMARC.pm line 274 MARC::File::USMARC::_build_tag_directory(MARC::Record=HASH(0x5607186ea458)) called at /usr/share/perl5/MARC/File/USMARC.pm line 313 MARC::File::USMARC::encode(MARC::Record=HASH(0x5607186ea458)) called at /usr/share/perl5/MARC/Record.pm line 474 MARC::Record::as_usmarc(MARC::Record=HASH(0x5607186ea458)) called at /usr/share/koha/lib/C4/Biblio.pm line 3054 C4::Biblio::ModBiblioMarc(MARC::Record=HASH(0x560718457c30), 348789, "") called at /usr/share/koha/lib/C4/Biblio.pm line 381 C4::Biblio::ModBiblio(MARC::Record=HASH(0x560718457c30), 348789, "") called at test_minimal.pl line 30 1 cim 7i 4500 =========^============== 1 Things I have checked: - /usr/share/koha/lib/C4/Biblio.pm has not been updated since well before the problems started - I can not see any plugins that do suspicious things Anyone got a hunch what might be causing this, or where to start looking for a solution? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20126] New: Saving a biblio does no longer update MARC field lengths
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20126 Bug ID: 20126 Summary: Saving a biblio does no longer update MARC field lengths Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 10455. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 31043] New: Marc records imports stuck at 0% or 4%
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31043 Bug ID: 31043 Summary: Marc records imports stuck at 0% or 4% Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: jheanelle.foster(a)nlj.gov.jm QA Contact: testopia(a)bugs.koha-community.org When trying to import staged marc records, it freezes at 4 %; another file freezes at 0%. Both files are over 6,000 records in length. The same happens on KOHA 21.11. On the contrary it accepts an import file of 1,700 records. Thanks for your assistance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11158] Authorities 'starts with' search returns the same as 'contains' when using ICU
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11158 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|colin.campbell@ptfs-europe. |dcook(a)prosentient.com.au |com | --- Comment #14 from David Cook <dcook(a)prosentient.com.au> --- Noticed this as one of the "10 Oldest bugs" under "Needs Signoff". Figured I'd update to the Assignee to me too since I apparently wrote the patch 1.5 years ago... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31026] New: Error while upgrading
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '22

27 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31026 Bug ID: 31026 Summary: Error while upgrading Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: keith(a)thesorbos.com QA Contact: testopia(a)bugs.koha-community.org While upgrading my database, I get the following error: Updating database structure Update errors : Upgrade to 21.12.00.016 [13:43:24]: Bug 30060 - Update user_permissions to add primary key and remove null option from code column ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate column name 'temp' at /usr/share/koha/lib/C4/Installer.pm line 739 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30781] New: Use of uninitialized value $val in substitution iterator at /usr/share/koha/lib/C4/Letters.pm line 665.
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30781 Bug ID: 30781 Summary: Use of uninitialized value $val in substitution iterator at /usr/share/koha/lib/C4/Letters.pm line 665. Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz In our installation 20.11.17 it's these lines: if (%$substitute) { while ( my ($token, $val) = each %$substitute ) { if ( $token eq 'items.content' ) { $val =~ s|\n|<br/>|g if $letter->{is_html}; } --> $letter->{title} =~ s/<<$token>>/$val/g; $letter->{content} =~ s/<<$token>>/$val/g; } } Itemscontent is used as: koha-foreach --chdir --enabled --email /usr/share/koha/bin/cronjobs/overdue_notices.pl -t -itemscontent date_due,title,subtitle,part_number,part_name,author,itemcallnumber,barcode koha-foreach --chdir --enabled --email /usr/share/koha/bin/cronjobs/advance_notices.pl -c --itemscontent date_due,title,subtitle,part_number,part_name,author,itemcallnumber,barcode This creates quite a bit of noise from the cronjobs, so it would be nice to get a hint on how to fix this or a patch. In master the code in question is unchanged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 30844] New: The OPAC detail page's browser is limited to the current page of results when using Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30844 Bug ID: 30844 Summary: The OPAC detail page's browser is limited to the current page of results when using Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: kevin.carnes(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org When viewing the detail page of the first or last record of a result page, it's not possible to browse to another page when using Elasticsearch. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 30726] New: Flatpickr's "yesterday" shortcut doesn't work if entry is limited to past dates
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30726 Bug ID: 30726 Summary: Flatpickr's "yesterday" shortcut doesn't work if entry is limited to past dates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 29478 If you configure a Flatpickr instance with the "pastdate" option (See the "Patrons with no checkouts" report, /cgi-bin/koha/reports/borrowers_out.pl), the "Yesterday" shortcut doesn't work. It should automatically select the previous day's date and populate the form field. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29478 [Bug 29478] flatpickr misses quick shortcut to "Today" date -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 30746] New: JS error on 'your personal details' in OPAC
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30746 Bug ID: 30746 Summary: JS error on 'your personal details' in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am seeing this error in the console in master: Uncaught TypeError: j is undefined Not sure if that is a local issue, could someone try and confirm? -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 30893] New: typo: update_patrons_category.pl fine(s)
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '22

26 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30893 Bug ID: 30893 Summary: typo: update_patrons_category.pl fine(s) Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: nick(a)bywatersolutions.com Reporter: evelyn(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz in the SYNOPSIS and OPTIONS portions of update_patrons_category.pl, the options fineover and fineunder do not match the GetOptions finesover and finesunder. The shortened versions can be used, but the plural/not plural should be fixed. -fo=X --fineover=X update if fines over X amount -fu=X --fineunder=X update if fines under X amount vs 'fo|finesover=s' => \$fine_min, 'fu|finesunder=s' => \$fine_max, -- You are receiving this mail because: You are watching all bug changes.

1 15