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

[Bug 29285] New: UI tests: Selenium 4 support
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 Bug ID: 29285 Summary: UI tests: Selenium 4 support Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Now v4 is the default when getting the docker image selenium/standalone-firefox . For Selenium 4, the maintainer of our current perl bindings wrote another client: https://metacpan.org/pod/Selenium::Client -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 33840] New: UpdateItemLocationOnCheckin needs a duration and library parameters
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33840 Bug ID: 33840 Summary: UpdateItemLocationOnCheckin needs a duration and library parameters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if we could define in UpdateItemLocationOnCheckin how long the change takes effect. Either add a |0 for indefinite, or |60 for 60 minutes (enter the duration in minutes. Maybe also have a |[BRANCH,ETC] or |[ALL] parameter to indicate what branches this would affect. That way, you could specify which branches to apply which timings to. The reason for this is that the reset to permanent is currently done through a cron, so we can't see this in settings, and it is global. It affects everyone. Some libraries return items to the shelf sooner than others. We could streamline this to adjust to each libraries reshelving rate. I guess the only issue would be the trigger for this. Should a cron job be checking these updates, and should there be a minimum on how often this cron runs so that it doesn't bog down the system? Would it bog down the system looking for items in shelving location at a branch? Should it be limited to hours and not minutes? Also, should UpdateItemLocationOnCheckin be left as a global setting, and should we have a branch level setting in the branches setups? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43298] New: Allow definition of distinct hours value in cart_to_shelf per itemtype
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43298 Bug ID: 43298 Summary: Allow definition of distinct hours value in cart_to_shelf per itemtype 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 Target Milestone: --- In bug 43297 I suggested allowing different cart_to_shelf periods per library. It would also be helpful to allow different periods per itemtype. For example, a library may re-shelve their DVDs with a couple hours but their books within a couple days. As mentioned on 43297, this could be implemented as cron options, but would be more user-friendly if set in the staff interface (and then trigged by the cron). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43297] New: Allow definition of distinct hours value in cart_to_shelf per library
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43297 Bug ID: 43297 Summary: Allow definition of distinct hours value in cart_to_shelf per library 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 Target Milestone: --- Currently the cart_to_shelf cron takes one hours value and applies it to items at any library. In a larger system, different libraries may have different expectations for how long an item should stay at the CART location after being returned. It would be helpful if the cron could be run with different hours values for different libraries. This would probably be simplest to implement just in the cronjob, though it may be more useful to pull that setup into the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43305] New: Migrate transfer_limits.tt to use api-client.js
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43305 Bug ID: 43305 Summary: Migrate transfer_limits.tt to use api-client.js 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: 34451 Target Milestone: --- admin/transfer_limits.tt uses raw jQuery.ajax() for POST and DELETE calls to /api/v1/transfer_limits. These need to be migrated to api-client.js for proper CSRF token handling (bug 34451). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 3030] Lost items (that are hidden) show up under Editions Tab
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3030 Rudy Hinojosa <rudy.hinojosa(a)lifeafter.solutions> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rudy.hinojosa(a)lifeafter.sol | |utions --- Comment #3 from Rudy Hinojosa <rudy.hinojosa(a)lifeafter.solutions> --- Created attachment 203672 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203672&action=e… lost items appear in refine search window. our settings are set to hidelost items from opac. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43304] New: Add global CSRF header injection for legacy jQuery.ajax API calls
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43304 Bug ID: 43304 Summary: Add global CSRF header injection for legacy jQuery.ajax API calls Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34451 Target Milestone: --- Bug 34451 adds CSRF protection for cookie-authenticated REST API requests. The http-client.js already sends the CSRF-TOKEN header automatically, but several templates still use raw jQuery.ajax() calls to the API without the header. Affected templates include: - members/two_factor_auth.tt (POST to /api/v1/auth/two-factor/registration and /verification) - tools/manage-marc-import.tt - tools/quotes.tt, quotes-upload.tt - tools/batch_modify_holds.tt - tools/stage-marc-import.tt These calls will fail with 403 when CSRF protection is active because they send the CGISESSID cookie (browser sends it automatically) but no CSRF-TOKEN header. Proposed fix: add a global jQuery.ajaxSetup that injects the CSRF-TOKEN header from the meta tag on every state-changing request: $.ajaxSetup({ beforeSend: function(xhr, settings) { if (!/^(GET|HEAD|OPTIONS)$/i.test(settings.type)) { var token = $('meta[name="csrf-token"]').attr('content'); if (token) xhr.setRequestHeader('CSRF-TOKEN', token); } } }); This fixes all legacy callers in one shot without requiring individual template changes. It should live in a globally included JS file (e.g., js/global.js or staff-global.js). Alternatively, individual templates could be migrated to http-client.js but that is a larger effort. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41903] New: Overdues reports in circulation module are too resource intensive
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41903 Bug ID: 41903 Summary: Overdues reports in circulation module are too resource intensive Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 circ module includes reports "Overdues" and "Overdues with fines." Both are sufficiently resources intensive as to cause noticeable slowdowns on large systems when used during business hours. They should be rewritten using APIs and VUE to improve performance. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 43303] New: 2FA_OTP_TOKEN notice title is "two-authentication step token"
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43303 Bug ID: 43303 Summary: 2FA_OTP_TOKEN notice title is "two-authentication step token" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- I found this while translating. I think the title should be something like "Two-factor authentication token" Same with the subject of the message, which is currently "Two-authentication token". It should be changed to "Two-factor authentication token" To recreate : 1. Go to Tools > Notices and slips 2. Search for 2FA --> Notice the title for 2FA_OTP_TOKEN is "two-authentication step token" 3. Click Edit next to 2FA_OTP_TOKEN 4. Click Email --> Notice the message subject is "Two-authentication token" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43241] New: REST API: q= parameter bypasses datetime conversion for values nested in DBIC operators
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43241 Bug ID: 43241 Summary: REST API: q= parameter bypasses datetime conversion for values nested in DBIC operators 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- When datetime filter values are passed inside DBIC operators (-and, -or) in the q= parameter, _recursive_fixup is never called on them. This means RFC3339 timestamps (e.g. 2026-08-05T00:00:00Z) reach MySQL unconverted. On tables with many rows (e.g. action_logs), MySQL cannot use the timestamp index when comparing against ISO 8601 format with the T separator, causing full table scans and very slow responses. The root cause is architectural: 1. _parse_dbic_query (in Koha::REST::Plugin::Query) maps field names but does not convert values 2. attributes_from_api (which calls _recursive_fixup for the conversion) is called on the merged result, but only iterates top-level keys 3. When the top-level key is -and or -or, the nested column values are passed through without fixup This affects any kohaTable-based page that combines default_filters with a global search term, since the DataTables layer wraps the combined query in -and. The fix: - Move attributes_from_api to process named query params before merging with q params - Teach _parse_dbic_query to call _recursive_fixup when it encounters a key that maps to a known column This ensures RFC3339 values are converted to MySQL-native format regardless of query nesting depth. Related: Bug 43208 (reported as a viewlog performance issue, same root cause) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23