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

[Bug 35135] New: Koha still needs certain leader tags despite removing them from the framework
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35135 Bug ID: 35135 Summary: Koha still needs certain leader tags despite removing them from the framework 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: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 157680 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=157680&action=e… Example records to use with the CSV2MARC plugin This is perhaps a unique set of circumstances, discovered while utilizing the CSV2MARC plugin. I have not tried to replicate this outside of the plugin. To recreate: 1. Create a framework called CSV2MARC by duplicating the Default framework but remove 000, 001, 003, 005, and 008 tags. 2. Create the CSV file. 3. Configure the plugin, matching the columns in the CSV file. 4. Stage and import the file selecting CSV as the format and CSV2MARC as the Framework. 5. Look at the detail view of the imported record and see that it has imported correctly. 6. Edit the record (do a minor edit like adding punctuation to a field) and save. 7. Look at the detail view of the imported record again and see that there is data loss. Now import the same record via z39.50. See that it imports correctly. Edit and save the record and see that all of the data for the record is retained. The z39.50 import uses the Default framework with the tags referenced above. The workaround was to correct the CSV2MARC framework and add back the 000, 001, 003, 005, and 008 tags, but mark the tag and subfields as not required. The CSV2MARC configuration and import works better by not trying to bring in the leaders (iow, its easier not to). If the ability exists to delete the tags in the framework and import a record with that framework, then there should not be data loss when editing and saving. Since these leader tags are important, at least as a space holder, then the ability to delete them in the framework should be disabled or a warning provided. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25163] New: Add the ability to bulk attach items to a bib record
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25163 Bug ID: 25163 Summary: Add the ability to bulk attach items to a bib record Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, a single item can be attached to a biblio record at one at a time. Libraries do have the need to do this in bulk as they could be possibly moving multiple items to another bib record and having the ability to do it in bulk would be beneficial. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 21983] New: Deleting a bib does not delete a request's link to it - missing foreign key
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21983 Bug ID: 21983 Summary: Deleting a bib does not delete a request's link to it - missing foreign key Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com illrequests.biblio_id should be a foreign key to biblio.biblionumber, but it's not! When a biblio is deleted, illrequests.biblio_id should be null-ed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 33697] New: Remove RecordedBooks (rbdigital) integration
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33697 Bug ID: 33697 Summary: Remove RecordedBooks (rbdigital) integration 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 17602 RecordedBooks search API integration is now obsolete following rbdigital's incorporation into OverDrive. Associated code should be removed. https://company.overdrive.com/2020/06/23/overdrive-to-acquire-rbdigital-fro… Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17602 [Bug 17602] Integrate support for RecordedBooks (formerly OneClickDigital) API -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 32332] New: bulkmarcimport.pl -insert fails to add MARC field 999
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32332 Bug ID: 32332 Summary: bulkmarcimport.pl -insert fails to add MARC field 999 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We have several libraries that have problems with their batch imports/updates from external sources after upgrading to 22.05.06. The problem is that records that are imported and/or updated via bulkmarcimport.pl do not get a 999 field, with the biblionumber in $c and $d. No 999 field is added at all. To reproduce in koha-testing-docker: - Edit koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml and remove the 952 field (otherwise Koha will complain about an undefined branchcode) - Import that file: $ sudo koha-shell -c "perl koha/misc/migration_tools/bulkmarcimport.pl -b -v -m=MARCXML -match=Control-number,001 -insert -l=/tmp/import.log -file koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml" kohadev - Check the result: $ sudo koha-mysql kohadev MariaDB [koha_kohadev]> SELECT biblionumber, ExtractValue(metadata, 'count(//datafield[@tag="999"])') AS count999 FROM biblio_metadata HAVING count999 = 0; This should give output like this: +--------------+----------+ | biblionumber | count999 | +--------------+----------+ | 439 | 0 | +--------------+----------+ 1 row in set (0.013 sec) ...meaning biblionumber 439 does not have a 999 field. - Updating the same record: $ sudo koha-shell -c "perl koha/misc/migration_tools/bulkmarcimport.pl -b -v -m=MARCXML -match=Control-number,001 -update -l=/tmp/import.log -file koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml" kohadev ...seems to add the 999 and make the problem go away: $ sudo koha-mysql kohadev MariaDB [koha_kohadev]> SELECT biblionumber, ExtractValue(metadata, 'count(//datafield[@tag="999"])') AS count999 FROM biblio_metadata HAVING count999 = 0; Empty set (0.009 sec) BUT on live servers (running 22.05.06, not master like in ktd) it looks like updating a record via bulkmarcimport.pl can cause an existing record to loose its 999 field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 36178] New: Add index for status on message queue table
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36178 Bug ID: 36178 Summary: Add index for status on message queue table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For large libraries, the query to gather pending notices from the message queue can take a very long time. ByWater's Rackpace DBA Mike was kind enough to do some work on this for us and found the issue. He recommends adding a simple index on the status column to fix this issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 34826] New: Circulation rules edit row select elements don't always update when selecting new row for editing
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34826 Bug ID: 34826 Summary: Circulation rules edit row select elements don't always update when selecting new row for editing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikko.liimatainen(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When editing circulation and fine rules selecting another row for editing without saving first can cause an issue where select elements on edit row don't update properly. This seems to be caused by adding additional selected values for select options each time different line is selected for editing. For example if you select each item type rule for editing you can have all item types selected on edit row select element after which that element doesn't update at all anymore when selecting new row for editing. I think clearing selected values from these select options each time when selecting new row for editing before adding selected value for the right option should fix the issue. At least there would no longer be conflict on which option value is actually selected. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 21676] New: Advanced editor - Rancor - complains on empty line at end
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21676 Bug ID: 21676 Summary: Advanced editor - Rancor - complains on empty line at end Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Minor usability irritation: Rancor complains about "Invalid tag number" on a completely empty line. You tend to automatically press enter at the end of a field, meaning you may have an empty line at the end of the record... and then Rancor complains when trying to save. Should instead just silently discard the empty line at the end before saving. Same complaint happens if there's an empty line in the middle, but I'm not sure if that should be silently discarded. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 36061] New: With IndependentBranches on a non-superlibrarian cannot modify password
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36061 Bug ID: 36061 Summary: With IndependentBranches on a non-superlibrarian cannot modify password Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marie-luce.laflamme(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the IndependentBranches system preference is turned on, non-superlibrarian staff without the 'view_borrower_infos_from_any_libraries' permission cannot change the patron's passwords, even if those patrons are from the same library. With the current behaviour, it's impossible to reset passwords from the intranet if your library doesn't have a staff member with superlibrarian powers. There are other bugs on similar topic, see: bug 12793 and bug 12599. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 30109] New: Wrong interface in logs when renewing patron
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30109 Bug ID: 30109 Summary: Wrong interface in logs when renewing patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I have not been able to recreate this in my testing environment, however, I can find evidence of the problem in many production environments. When renewing a patron the interface recorded in action logs is often 'api' SELECT * FROM action_logs WHERE module='MEMBERS' AND action="RENEW" AND interface='api'; The specific log is from Koha::Patron->renew_account This is only called in members/setstatus.pl setstatus uses 'checkauth' rather than other routines for verifying logged in patron, and it seems that the interface must not be set for Context in that call -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12