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

[Bug 33905] New: Username and cardnumber should be unique respectively
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '26

05 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33905 Bug ID: 33905 Summary: Username and cardnumber should be unique respectively Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently Koha allows a user to sign in with either their cardnumber or userid Confusion can arise when a user has a username that is another users cardnumber, and vice versa We should check uniqueness across both of these fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 41206] New: Add collection code to transfers to receive
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41206 Bug ID: 41206 Summary: Add collection code to transfers to receive Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 42425] New: Add checkin_id FK to accountlines to link fee adjustments to checkin events
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42425 Bug ID: 42425 Summary: Add checkin_id FK to accountlines to link fee adjustments to checkin events Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42418 Blocks: 24401 When AddReturn processes a checkin, it may create or modify several accountlines (lost item fee refunds/charges, processing fee refunds, etc.). Currently these fee adjustments have no persistent link back to the checkin event that triggered them. Bug 42418 introduced the checkins table as a first-class resource. Adding a checkin_id FK to accountlines would: - Allow Koha::Checkin->account_lines as a proper relationship - Enable embedding account_lines in the checkin REST API response (bug 24401) - Provide an audit trail linking financial transactions to the specific checkin that caused them - Eliminate the need to infer fee changes from timestamps or $messages parsing Implementation notes: - Add checkin_id INT(11) DEFAULT NULL to accountlines with FK to checkins.checkin_id ON DELETE SET NULL - Update AddReturn to pass the checkin_id when creating/modifying accountlines during return processing - The relevant C4::Circulation code paths are: _FixAccountForLostAndFound, _FixOverduesOnReturn, and the lost item fee charge logic Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 [Bug 24401] REST API: Check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42418 [Bug 42418] Add Koha::Checkin(s) - checkin as a first-class resource -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 42418] New: Add Koha::Checkin(s) â checkin as a first-class resource
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42418 Bug ID: 42418 Summary: Add Koha::Checkin(s) â checkin as a first-class resource 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 41728 Blocks: 24401 Checkins in Koha are currently a side effect â they happen to checkouts, transfers, and holds, but there is no single record that captures 'a staff member scanned this item and here is what happened.' This bug introduces checkins as a proper resource: - New `checkins` table tracking the full context (who, what, where, when) and outcomes (checkout returned, transfer triggered, hold filled) - Koha::Checkin and Koha::Checkins object classes - Wire into AddReturn so every checkin path (returns.pl, SIP, API) produces a Koha::Checkin record This addresses several long-standing gaps: - 'Who checked this in?' is currently unreliable (no checkin_user_id on old_issues) - Transfers and holds triggered by a return have no causal link back to the scan - Lost item fee refunds cannot be traced to the return event that caused them - Plugins (e.g. Rapido ILL) have to reconstruct context from side effects Depends on bug 41728 (checkin availability). Blocks bug 24401 (checkin REST API endpoint). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 [Bug 24401] REST API: Check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136

[Bug 35267] New: Add further CSS options for Notices
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35267 Bug ID: 35267 Summary: Add further CSS options for Notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org During review of bug 33487 I made the suggestion that we should have more CSS options for our notices at the system preference level. I've also hit this when looking into bug 30287. So.. recording this here and hopefully we'll find some time to work on it. Personally.. I'd have * EmailNoticeCSS - CSS stored in the DB for email notice CSS * EmailNoticeCSSHosted - Location of CSS file for email notice CSS (to retain the old NoticeCSS option) * PrintNoticeCSS - CSS stored in the DB for print notice CSS * PrintNoticeCSSHosted - Location of the CSS file for the print notice CSS (to reatin the old SlipCSS option) SMS doesn't support HTML/CSS so no need for that transport type to have these CSS options. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 316

[Bug 36702] New: Background Jobs:Add option to retry failed jobs with a max tries parameter
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36702 Bug ID: 36702 Summary: Background Jobs:Add option to retry failed jobs with a max tries parameter 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the background jobs just fail. It would be helpful if there was a path to add or set background jobs with a parameter to retry x times (probably with a y seconds interval between?) especially now that plugins can add background jobs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 41921] New: Add ability to run reports as background jobs
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41921 Bug ID: 41921 Summary: Add ability to run reports as background jobs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com It would be nice if reports can as background jobs instead of standard page loads. This would allow long running reports to be viewable from the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 131

[Bug 42351] New: Add header for tracing API requests
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42351 Bug ID: 42351 Summary: Add header for tracing API requests Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com For debugging purposes, it would be useful to have Koha generate a UUID and send it in a header with each API request. It seems that X-Request-ID is a commonly used header. It might be useful to also send a header that indicates that Koha itself is making the request since X-Request-ID may imply that, but isn't explicit. Maybe we add an X-Koha-Origin header with a value of "koha", or maybe a single header with a more Koha-specific name like X-Koha-Request-ID. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 40898] New: Add ability to limit the number of columns a patron search api request can sort by
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40898 Bug ID: 40898 Summary: Add ability to limit the number of columns a patron search api request can sort by Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Patron API searches can order by any borrowers column and can specify any number of columns to order by as well. Given sufficient numbers of patrons and unindexed columns sort by, the search query generated will create a temp table so large it can fill up the temp disk and prevent the db server from functioning. A reasonable solution would be to create a system preference to set a maximum number of columns to sort by. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42373] New: Add ability to disallow unbounded patron api searches
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42373 Bug ID: 42373 Summary: Add ability to disallow unbounded patron api searches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In a Koha instance with multiple hundreds of thousands of patrons, a patron api search with _per_page=-1 can cause a single worker to query the database for all patrons, then query the database multiple times for each of those patrons to decorate the resulting patrons ( fees owed, etc ). If the _per_page size is greater than the limit we specify, Koha should refuse the request and emit an http status code 400, with a clear error body explaining the max allowed _per_page value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36