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

[Bug 26775] New: Cannot put newly imported authority into biblio field
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '24

06 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26775 Bug ID: 26775 Summary: Cannot put newly imported authority into biblio field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Open authority finder on say field 100 (author) Click Create new authority Click Z3950 search Import a new authority No way to choose this authority and put it in the 100 field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 32631] New: Error when previewing record during batch record modification
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '24

06 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32631 Bug ID: 32631 Summary: Error when previewing record during batch record modification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: critical Priority: P5 - low Component: Tools Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org After submitting a batch of bibliographic records for modification, clicking the "Show MARC" buttons don't work. An error is in the console: Can't call method "as_formatted" on an undefined value at /kohadevbox/koha/svc/records/preview line 74 -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 32160] New: Batch record modification - show MARC preview no longer works
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '24

06 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32160 Bug ID: 32160 Summary: Batch record modification - show MARC preview no longer works Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When clicking on the 'Show MARC' action from the list of records to be modified using Cataloguing > Batch record modification, it shows as 'Loading' and does not complete the display of the modified MARC record. In the web developer tools an error is displayed: 14:24:26.131 XHR GET http://127.0.0.1:8081/cgi-bin/koha/svc/records/preview?record_type=biblio&r… [HTTP/1.1 500 Internal Server Error 87ms] To replicate using koha-testing-docker (KTD): 1. Add a MARC modification template (Cataloguing > MARC modification templates > New template > give it a name and click submit > add a 'New action" (for example: Add new 500$a with value 'OK')). 2. Modify a batch of records (Cataloguing > Batch record modification): - For 'Enter a list of record numbers' enter 17 and 262 (sample data for KTD) - Choose the template you created in step 1 - Press Continue 3. Enable the web developer tools console. 3. From the results list, click on 'Show MARC'. 4. On the modal window, note that the spinner says 'Loading', and doesn't complete the display of the MARC. 5. Note that in the web developer tools console there is an error: 14:24:26.131 XHR GET http://127.0.0.1:8081/cgi-bin/koha/svc/records/preview?record_type=biblio&r… [HTTP/1.1 500 Internal Server Error 87ms] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

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

06 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