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

[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 41539] New: Include item barcode in waiting hold message on patron record
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41539 Bug ID: 41539 Summary: Include item barcode in waiting hold message on patron record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The "Hold Waiting" message that appears on the Check Out and Details pages of the patron record does not include the barcode for the waiting item. In some instances that barcode would be useful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[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 41677] New: Use template wrapper for tabs: OAI repositories
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41677 Bug ID: 41677 Summary: Use template wrapper for tabs: OAI repositories Initiative type: --- Sponsorship --- status: 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 Depends on: 32571 The OAI repositories search include (oai-admin-search.inc, included on admin/oai_servers.pl) was missed when we were transitioning to using a template wrapper for tabs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32571 [Bug 32571] Use template wrapper to build tabbed components -- You are receiving this mail because: You are watching all bug changes.

1 16

[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 41840] New: Number in patron's Holds tab doesn't update for new groups until page is reloaded
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41840 Bug ID: 41840 Summary: Number in patron's Holds tab doesn't update for new groups until page is reloaded Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com With the new hold groups feature, the number next to the Holds label in a patron's Holds table (staff interface view) lists the combined number of groups and individual holds. For instance, if a patron has one group hold with two bibs, and then two individual holds, the number next to Holds will read 3. However, if a staff member creates a new group from that screen by adding one of the ungrouped holds to the existing group, the number next to the Holds label will still show as 3 until the page is reloaded. Once it's reloaded, the number will correctly update to 2 (one group with three bibs, and one individual hold). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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