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

[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 42184] New: Transfer requests between the ILL module and purchase suggestsions
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42184 Bug ID: 42184 Summary: Transfer requests between the ILL module and purchase suggestsions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com It would be extremely helpful if there were a way to move an ILL request to purchase suggestions, or vice versa. Some things we might want to purchase, and some we only want to borrow. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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 42258] New: CSP OPAC: LibraryThing widget.js blocked
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42258 Bug ID: 42258 Summary: CSP OPAC: LibraryThing widget.js blocked Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org To test: 1. Enable preference LibraryThingForLibrariesEnabled 2. Set preference LibraryThingForLibrariesID = 1 3. Have at least one record catalogued 4. Open your browser's developer tools -> Console 5. Navigate to OPAC 6. Search any record and navigate to its details page 7. Observe the following error in your developer tools console Loading the script 'https://ltfl.librarything.com/forlibraries/widget.js?systype=koha&id=1' violates the following Content Security Policy directive: "script-src 'self' 'nonce-4rNHb7Wy5TpA327q_M8g90'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. The action has been blocked. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 42257] New: Webhook option instead of SMTP output.
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42257 Bug ID: 42257 Summary: Webhook option instead of SMTP output. Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: rudy.hinojosa(a)lifeafter.solutions QA Contact: testopia(a)bugs.koha-community.org New Feature request: Add an option to specify an outgoing webhook, that will be provided by the Koha administrator. This could allow outbound message_queue emails to be sent to this webhook instead of an smtp provider. The contents of the message body could be sent via a json body via the webhook. The body could include the To emails , cc email addresses and bcc optionally. This would be super useful for those wanting to use zapier, integromat, or make dot com to handle more integrations remotely and ultimately pass the email through a 3rd party handler. For example, a staff member could receive a notification in mattermost, rocketchat, slack and many others that an email contained certain keywords, that a librarian or developer should be aware of immediately. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42256 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42256 [Bug 42256] Ungrouping holds can leave patron with more holds than they should have -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42255 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42255 [Bug 42255] Grouped holds counted inconsistently for circ rules -- You are receiving this mail because: You are watching all bug changes.

1 0

[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