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

[Bug 10417] Add table to keep deleted authorities
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10417 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** This bug has been marked as a duplicate of bug 30888 *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10400] Text::CSV_XS error-checking should be standardized
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10400 --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Galen Charlton from comment #0) > As reported by Doug Kingston on koha-devel on 2013-06-02, if version 0.97 of > Text::CSV_XS is installed, it can segfault. From Doug's email: > > "The error from t/Labels.t is a segmentation fault when calling > $csv->error_input() in Labels/Label.pm. > > sub _get_text_fields { > my $format_string = shift; > my $csv = Text::CSV_XS->new({allow_whitespace => 1}); > my $status = $csv->parse($format_string); > my @sorted_fields = map {{ 'code' => $_, desc => $_ }} > map { $_ eq 'callnumber' ? 'itemcallnumber' : $_ } > # see bug 5653 > $csv->fields(); > my $error = $csv->error_input(); > warn sprintf('Text field sort failed with this error: %s', $error) if > $error; > return \@sorted_fields; > }" > > A ticket was opened with the maintainer of Text::CSV_XS > (https://rt.cpan.org/Ticket/Display.html?id=85810) and he fixed the > segfault bug in version 0.98 of the module. koha-testing-docker shows the version installed as: Text::CSV_XS (0.32 ) 1.45 So I guess we could assume that most installations have this fix by now. > > Nonetheless, Koha code that uses Text::CSV_XS should follow the module's > documentation more closely; in particular, it looks like the correct thing > to do is the check the value of the $status returned by $csv->parse() before > deciding whether to invoke error_input(). It looks like we do the status check on patron import: my $status = $self->text_csv->parse($borrowerline); my @columns = $self->text_csv->fields(); if ( !$status ) { push @missing_criticals, { badparse => 1, line => $line_number, lineraw => decode_utf8($borrowerline) }; } But there has not been any change in Labels: sub _get_text_fields { my $format_string = shift; my $csv = Text::CSV_XS->new({allow_whitespace => 1}); my $status = $csv->parse($format_string); my @sorted_fields = map {{ 'code' => $_, desc => $_ }} map { $_ && $_ eq 'callnumber' ? 'itemcallnumber' : $_ } # see bug 5653 $csv->fields(); my $error = $csv->error_input(); warn sprintf('Text field sort failed with this error: %s', $error) if $error; return \@sorted_fields; -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10393] To add some shortcuts to acquisitions main screen e.g. RECEIVE SHIPMENT and the FILTER BOX
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10393 --- Comment #8 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I still believe that this is just a reverse of steps without providing an additional benefit. More so: if you have a few hundred vendors, which especially special libraries tend to have, a simple pull down list is not ergonomic for selecting the vendor. Spinning this a little differently: Maybe we could allow to create an invoice/shipment without selecting a vendor first and pick the vendor automatically from the first order chosen? This way we might achieve what the library intended. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10387] checkauth and get_template_and_user have copy-pasta for setting template variables
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10387 --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Can someone tell if this is still valid? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10342] Better display of UNIMARC thesis note in XSLT is needed
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10342 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Better display of UNIMARC |Better display of UNIMARC |thesis note in xslt is |thesis note in XSLT is |needed |needed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10280] Extend SeparateHoldings functionality to the "Add items" screen
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10280 --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Katrin Fischer from comment #2) > I really like this idea of a tabbed display for items by branch. It would > help pick your 'own' items easier even without IndependentBranches. I still like this idea :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10502] Add independent branches option for sql reports
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10502 Bug 10502 depends on bug 10263, which changed state. Bug 10263 Summary: Add ability to limit which library can edit a bibliographic record https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10263 What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10263] Add ability to limit which library can edit a bibliographic record
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10263 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |RESOLVED Resolution|--- |DUPLICATE --- Comment #15 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** This bug has been marked as a duplicate of bug 28743 *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28743] New: With IndependentBranches block changes to biblio records shared with other libraries
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28743 Bug ID: 28743 Summary: With IndependentBranches block changes to biblio records shared with other libraries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 28323] New: Invalid record in sample data leading to error when displaying
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28323 Bug ID: 28323 Summary: Invalid record in sample data leading to error when displaying Change sponsored?: --- Product: Koha Version: master 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: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Strk̆v̜elser illustreret af Jean Anderson dansk udgave ved Lis Engel [overst̆telse ved Jesper Langer] staff://cgi-bin/koha/catalogue/detail.pl?biblionumber=369 opac://cgi-bin/koha/opac-detail.pl?biblionumber=369 ========= error ============ Invalid data, cannot decode metadata object (biblio_metadata.id=368, biblionumber=369, format=marcxml, schema=MARC21, decoding_error=':8: parser error : PCDATA invalid Char value 31 <controlfield tag="001">00aD000015937</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ============ Here is some analysis by Caroline ============ I can't find the exact problem with record 369, but it's definitely problematic, even MarcEdit won't open it I can view it with a command line tool that I have Problem record : https://snipboard.io/paTtIK.jpg the error messages seem to point to the control fields 001, 004 (which doesn't exist in MARC21 afaik), and 008 Compared with a healthy record : https://snipboard.io/XFZ5VN.jpg In fact, there are a couple more fields in the problem record that dont exist in MARC21 : 021 (should probably be 020), 245$d (should probably be 245$c?), 245$f should be dates The fact that indicators are all 00 is also wierd... anywho, I think there is probably a character at the beginning of the record that is messing up everything else tuxayo: does this look like a legitimate record to have in sample data? Because real world data can be weird ^^ tuxayo: Or is this worthless and should be removed from sample data? caroline: I think it should be removed.... I mean it's just sample data and this one is clearly a problem Unless it was there for a specific purpose like you suggested it causes problem when searching for danish documents too :/ Advanced search > Language Danish > Search > Error ====== issue with search of Danish records ======= - OPAC - advanced search - Language dropdown => Dansk - search - error Actually it's just that it redirects to the record page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6