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

[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

[Bug 31380] New: Build Mojolicious controller for running Koha plugins
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31380 Bug ID: 31380 Summary: Build Mojolicious controller for running Koha plugins 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, Koha plugins run via Plack::App::CGIBin, which buffers responses and otherwise prevents plugins from fully leveraging the power of Plack and Mojolicious. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81

[Bug 33768] New: We need tests for the OAuth2/OIDC client
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33768 Bug ID: 33768 Summary: We need tests for the OAuth2/OIDC client Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40188] New: SUSHI has been renamed to COUNTER API
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40188 Bug ID: 40188 Summary: SUSHI has been renamed to COUNTER API Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, michaela.sieber(a)kit.edu, pedro.amorim(a)openfifth.co.uk Depends on: 39345 With the latest release of the COUNTER standard the protocol has been renamed from SUSHI to COUNTER API. https://www.countermetrics.org/wp-content/uploads/2024/04/Printable-Changes… At some point we might want to reflect that in the GUI as well. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39345 [Bug 39345] Koha must support COUNTER 5.1 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 37808] New: api.koha-community.org should be linked to from the main manual
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37808 Bug ID: 37808 Summary: api.koha-community.org should be linked to from the main manual Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de We currently don't highlight that there are publically available API docs available from the main documentation site: https://koha-community.org/manual/latest/en/html/webservices.html#versioned… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31557] New: Hold queue/home vs. holding library/transport cost matrix complications
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31557 Bug ID: 31557 Summary: Hold queue/home vs. holding library/transport cost matrix complications Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com It would be helpful if build_holds_queue.pl either 1) checked items' holding libraries in addition to home when items float, or 2) used the Transport Cost Matrix instead when systems have it enabled. Using home library only/first results in higher 'costs' and in holds being filled more slowly than necessary, and can be confusing for libraries. Home/holding: If I understand correctly, build_holds_queue.pl looks for items whose home library matches the hold's pickup library (plus accounting for any preferences set in StaticHoldsQueueWeight/HoldsQueueSkipClosed/RandomizeHoldsQueueWeight). For example, in a system where items float, a hold to be picked up at West library has the following items: Item 1: Home library West, holding library East Item 2: Home library West, holding library West Item 3: Home library North, holding library West If build_holds_queue.pl sees Item 1 first, it will be placed on East's queue to send to West even though Item 2 is already at West and could fill the hold more efficiently. Then since the Transport Cost Matrix is only consulted if no available items have a home library matching the hold's pickup library, holds are filled in a more 'expensive' way than libraries may expect. Using the Transport Cost Matrix directly would address this. For example, in a system where items float and a hold is to be picked up at South: Item 1: Home library East, holding library South Item 2: Home library West, holding library West Item 3: Home library South, holding library West build_holds_queue.pl will see that Item 3 has a home library matching the pickup library and will place it on West's queue to send to South. If build_holds_queue.pl consulted the Transport Cost Matrix, Item 1 would be placed on South's queue with no transfer necessary. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 37221] New: No way to turn off Overdrive integrations without removing all syspref values
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37221 Bug ID: 37221 Summary: No way to turn off Overdrive integrations without removing all syspref values Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If the Overdrive API goes down, having this integration on at a busy site can cause backlogs due to timeouts that can only be mitigated by disabling the integration. As it stands to disable the integrations, you have to remove all of the values from the Overdrive preferences. It would be nice to be able to turn this integration on and off with a single syspref, retaining any previously supplied values for the overdrive integration. -- You are receiving this mail because: You are watching all bug changes.

1 18