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

[Bug 40719] New: Explicit turn off RELATIVE file paths for plugins for user-entered templates
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40719 Bug ID: 40719 Summary: Explicit turn off RELATIVE file paths for plugins for user-entered templates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In bug 39184 we set EVAL_PERL and ABSOLUTE to 0, which is the default. RELATIVE also defaults to 0. For security we should probably specify that as well in case the default is changed somehow. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 39715] New: Do not quote DataTables options
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39715 Bug ID: 39715 Summary: Do not quote DataTables options Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Koha templates are inconsistent when it comes to quoting DataTables options: (https://gitlab.com/koha-community/Koha/-/blob/main/koha-tmpl/intranet-tmpl/…) var cities_table = $("#table_cities").kohaTable({ "ajax": { "url": cities_table_url }, "order": [[ 1, "asc" ]], "columnDefs": [ { "targets": [0,1,2,3,4], "render": function (data, type, row, meta) { if ( type == 'display' ) { if ( data != null ) { return data.escapeHtml(); } else { return ""; } } return data; } } ], Options in this example like "ajax", "order", and "columnDefs" are quoted in this example but other templates will have unquoted options. I think we should standardize on having no quotes around the options. The quotes are unnecessary, and inconsistent with up-to-date DataTables documentation. -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 40031] New: MARC modification templates should have a unique URL
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40031 Bug ID: 40031 Summary: MARC modification templates should have a unique URL Change sponsored?: --- Product: Koha Version: 24.11 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 To replicate: 1. Go to Cataloging > MARC Modification templates note the URL = /cgi-bin/koha/tools/marc_modification_templates.pl 2. Add a new template notice the URL = /cgi-bin/koha/tools/marc_modification_templates.pl It would be nice if the template name is incorporated into the URL so the URL can be shared and the user can be taken directly to a template. Currently the user has to go to /cgi-bin/koha/tools/marc_modification_templates.pl and search for the template to see the actions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 40769] New: Highlight hold fees when placing a hold from the staff client
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40769 Bug ID: 40769 Summary: Highlight hold fees when placing a hold from the staff client Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com We don't notify staff up front that a hold fee will be applied to the patrons account when placing a hold from the staff client.. we should. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 40552] New: Allow selecting all holds from a group
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40552 Bug ID: 40552 Summary: Allow selecting all holds from a group Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 40551] New: Make patron page holds table use API endpoint for cancellation
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40551 Bug ID: 40551 Summary: Make patron page holds table use API endpoint for cancellation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 38115] New: Add FTP support to export_records.pl
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38115 Bug ID: 38115 Summary: Add FTP support to export_records.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz With an administrative UI for configuring FTP connections coming but bug 35761 it would be nice to add support for using those connections in the misc/export_records.pl script. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 39972] New: Blank bib heading fields link to unrelated authority records
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39972 Bug ID: 39972 Summary: Blank bib heading fields link to unrelated authority records Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you save a bib record with a heading field (1xx, 6xx, etc.) containing a blank subfield a or other subfields but no subfield a, Koha incorrectly links the field to an authority record. It's not a blank authority, but a proper authority record of the same type (personal, topical etc.) but a nonmatching heading. It seems to target the same records each time, so in my system a blank personal name field (100, 600, etc.) always links to authority ID #1, for the Achaemenid dynasty. A blank X10 links to authority #48, for the Catholic Church, and so on. The situations described are cataloging errors in the bib record and so unwelcome, but they should not automatically link to valid but unrelated authorities. They should remain unlinked. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31520] New: Only log ILL changes that are actual changes
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31520 Bug ID: 31520 Summary: Only log ILL changes that are actual changes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no "Bug 20750 - Allow timestamped auditing of ILL request events" added the ability to log status changes to ILL requests, in the action_logs table, with action = 'STATUS_CHANGE'. I have an ILL setup where a remote API is checked for data every 3 minutes, and requests are updated. With Illlog = on, this leads to 480 action_logs entries per 24-hour period. I have a test setup where the amount of logs was causing the detailed display of illrequests to time out, because there were so many log entries to fetch. This could be improved if we only logged actual status changes. Today there is a log entry even if the status is not changed: | ILL | STATUS_CHANGE | {"status_after":"IN_LEV","log_origin":"core","status_before":"IN_LEV"} | | ILL | STATUS_CHANGE | {"status_after":"IN_LEV","status_before":"IN_LEV","log_origin":"core"} | | ILL | STATUS_CHANGE | {"status_before":"IN_LEV","status_after":"IN_LEV","log_origin":"core"} | | ILL | STATUS_CHANGE | {"log_origin":"core","status_before":"IN_LEV","status_after":"IN_LEV"} | | ILL | STATUS_CHANGE | {"status_before":"IN_LEV","status_after":"IN_LEV","log_origin":"core"} | | ILL | STATUS_CHANGE | {"status_after":"IN_LEV","log_origin":"core","status_before":"IN_LEV"} | +--------+---------------+------------------------------------------------------------------------+ We could compare status_before and status_after, and only log if they differ. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32896] New: Can we move autoBarcode handling into Koha::Item->store() ?
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32896 Bug ID: 32896 Summary: Can we move autoBarcode handling into Koha::Item->store() ? Change sponsored?: --- Product: Koha Version: unspecified 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently, the codebase is somewhat littered with calls to check the autoBarcode pref and then generate a barcode.. could we remove these calls from the various controllers and move it to one call in Koha::Item->store() instead? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10