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

[Bug 29577] New: Link bibs to authorities fails if relator terms are in records to be linked
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29577 Bug ID: 29577 Summary: Link bibs to authorities fails if relator terms are in records to be linked Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you use a relator ($e) in the authority and biblio records and run link_bibs_to_authorities.pl, it does not link the records although they are a match Observed at 20.11.09 Workflow: 1. Add PERSONAL authority record with 100a Berridge, Elizabeth and 100e actor 2. Add new biblio record with 700a Berridge, Elizabeth and 700e actor NB/ 700 Field should not be under authority control whilst this data is entered to simulate data that is not linked. Temporarily amend this in cataloguing template for 700 field 3. Run link biblio script on the new test bib's biblionumber: sudo koha-shell -c "/usr/share/koha/bin/link_bibs_to_authorities.pl --bib-limit='biblionumber=<yourbibnumber>' --verbose" <site> 4. Observe log which will say Number of bibs checked: 1 Number of headings linked: 0 Number of headings unlinked: 1 5. Remove 100e actor (from authority) and 700e actor (from biblio) and save 6. Rerun linker script (step 3) Number of bibs checked: 1 Number of headings linked: 1 Number of headings unlinked: 0 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 25098] New: automatic item modification needs report function
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25098 Bug ID: 25098 Summary: automatic item modification needs report function Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The automatic item modification cronjob does not have an option for reporting the items that were modified. Can the cronjob log in action_logs, or as a report that's emailed, or into a logfile that can be downloaded? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 34417] New: ERM's breadcrumb (Vue) does not display the entity's name
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34417 Bug ID: 34417 Summary: ERM's breadcrumb (Vue) does not display the entity's name Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 33169 For instance we have "Show agreement" instead of the agreement's name. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33169 [Bug 33169] Improve vue breadcrumbs and left-hand menu -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 21670] New: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21670 Bug ID: 21670 Summary: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org On run #72, Koha_Master_U18 failed: koha_1 | Could not unlink /tmp/xRRc7ht/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm.pm: No such file or directory at /kohadevbox/koha/Koha/Plugins/Handler.pm line 105. koha_1 | koha_1 | # Failed test 'Koha::Plugins::Handler::delete works correctly.' koha_1 | # at t/db_dependent/Plugins.t line 127. koha_1 | # Looks like you failed 1 test of 39. koha_1 | [15:24:05] t/db_dependent/Plugins.t ................................................ koha_1 | Dubious, test returned 1 (wstat 256, 0x100) koha_1 | Failed 1/39 subtests We requested another run and it passes (#73), same node (Docker_3) -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 36094] New: svc/authentication not used
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36094 Bug ID: 36094 Summary: svc/authentication not used Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Looks like we can remove it. -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 35987] New: See highlighted items below link broken
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35987 Bug ID: 35987 Summary: See highlighted items below link broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On circulation.pl and moremember.pl the "see highlighted items below" link goes to #checkouts, but there is no div #checkouts instead of #checkouts_panel -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 32575] New: gather_print_notices.pl sends HTML file as body of email
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32575 Bug ID: 32575 Summary: gather_print_notices.pl sends HTML file as body of email Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org gather_print_notices.pl can send print notices to the library, as an HTML file attached to an email. At least some libraries report that the HTML does not come as an attached file, but as the body of the email. This breaks printing the notices properly. I am not sure if this is a problem with the emails generated by gather_print_notices.pl or with the email clients (or other software) used by the libraries that have this problem. A quick solution has been to add some body text to the emails generated by gather_print_notices.pl: 299 my $email = Koha::Email->create( 300 { 301 from => $from, 302 to => $to, 303 subject => 'Print notices for ' . $today_syspref, 304 text_body => 'See attached file.', # <==== Added this 305 } 306 ); This seems to force the attachment to be seen as an attachment, and not as the body of the email. In the headers of the emails sent by the standard gather_print_notices.pl I have seen this: Content-Transfer-Encoding: base64 Content-Type: text/html; charset=iso-8859-1 PCFET0NU... [lots of base64] When I have added some body text it looks more like this: Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="16633311691.0Ab5.3555417" --16633311691.0Ab5.3555417 Date: Fri, 16 Sep 2022 14:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable See attached file. --16633311691.0Ab5.3555417 Date: Fri, 16 Sep 2022 14:26:09 +0200 MIME-Version: 1.0 Content-Type: text/html; name="notices_all-2022-09-16-KOHA.html" Content-Disposition: attachment; filename="notices_all-2022-09-16-KOHA.html" Content-Transfer-Encoding: base64 PCFET0... [lots of base64] So unless something is changed on the way from Koha to the mail client, it looks like gather_print_notices.pl sends the HTML from the document as the body of the email. Not sure if this is a problem in Koha::Email->create that should be fixed there, or if it makes sense to just add some default text to the email, to fix the problem in the least obtrusive way? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 35483] New: Restore item level to record level hold switch in hold table
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35483 Bug ID: 35483 Summary: Restore item level to record level hold switch in hold table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 33575 commit [1] has reverted hold level switch feature added in Bug 31692 commit [2] to holds table. Switching item level holds to record level holds no longer works in the table. Let's restore the feature in this Bug. [1] https://github.com/Koha-Community/Koha/commit/c649f73d029b406a6bad80c31b838… [2] https://github.com/Koha-Community/Koha/commit/b0f49d5dafa4e2dcc05e1e85c13cd… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 27363] New: Restore temporary selection of Z39.50 targets throughout multiple searches
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27363 Bug ID: 27363 Summary: Restore temporary selection of Z39.50 targets throughout multiple searches Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Prior to 20.05.06, when using Z39.50 in the Advanced Cataloging Editor, servers that were selected each time a new Z39.50 search was done would be retained throughout multiple searches. This is no longer the case. It would be helpful if that behavior was restored. We have preselected servers which persist for all searches. As we catalog we add some additional servers that would be retained for a short period of time until we decided we no longer needed them. For instance, we may be cataloging Spanish and we could check a server that could be used for several bibs but it wasn't a server that we wanted to be a preselected server. Now that a newly checked server is not retained in the short term we have to check it again for every search which is much less efficient. We could go into Admin and make it a preselected search for the short duration we plan to use it and then go back into Admin to uncheck it when done but that is also not efficient. It would be so much more efficient to be able to check a new server, have it retained, and then uncheck it when done. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 36196] New: Handling NULL data in ajax calls for cities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36196 Bug ID: 36196 Summary: Handling NULL data in ajax calls for cities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello all, Just a simple patch here, I had the case recently, if a data is null in the cities table, the datatable won't handle the data well and will load indefinitely. I've added a condition so that it can be displayed despite NULL data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26