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

[Bug 43215] New: Checkbox/sortable system preferences show one 'Saved preference' message per option instead of per preference
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43215 Bug ID: 43215 Summary: Checkbox/sortable system preferences show one 'Saved preference' message per option instead of per preference Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration 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 Depends on: 42553 Target Milestone: --- Found while testing bug 42553 (multiple_sortable: authval dispatcher for admin/preferences.pl). When a system preference uses the multiple_sortable (checkbox-group) widget in admin/preferences.pl - e.g. OPACAuthorIdentifiersAndInformation, ArticleRequestsSupportedFormats, or a new authval-sourced pref such as the one added by bug 42553 - saving the preference from Administration > System preferences pops up one "Saved preference ..." confirmation line per checkbox/option, instead of a single line for the preference itself. For example, saving a pref called TestSortableAV with two selected authorised values produces: Saved preference TestSortableAV_CASH Saved preference TestSortableAV_SIP00 Root cause: in koha-tmpl/intranet-tmpl/prog/js/pages/preferences.js, the ".preference-checkbox" change handler marks every checkbox of every checkbox-group preference on the page as "modified" (not just the ones belonging to the changed preference), and dragging an item in the SortableJS list synthetically fires change() on the list's first checkbox, triggering the same global marking. KOHA.Preferences.Success() then builds the confirmation message by iterating every ".modified" element and using its own DOM id (which is per-checkbox, e.g. pref_TestSortableAV_CASH), rather than grouping by the underlying preference name. This is pre-existing behaviour, reproducible today on main with the existing checkbox-group prefs. It is not introduced by bug 42553, but that patch makes the widget easier to reach for new prefs, which is how it was noticed during QA. Test plan: 1. On a system with a multiple_sortable/checkbox-group syspref (e.g. OPACAuthorIdentifiersAndInformation), select two or more checkboxes and save. 2. Note the confirmation message contains one "Saved preference ..." line per checkbox rather than one line for the preference. 3. Expected: a single confirmation line per changed preference, regardless of how many checkboxes/options it contains. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42553 [Bug 42553] preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 42553] New: preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42553 Bug ID: 42553 Summary: preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The 'choices' renderer in admin/preferences.pl already supports a dynamic 'authval' source pattern, where the YAML can say: choices: authval source: SOMECATEGORY and the choices are populated from the named authorised value category at render time. The 'multiple_sortable' renderer (the SortableJS-backed drag-and-drop multi-select used by OPACAuthorIdentifiersAndInformation and ArticleRequestsSupportedFormats) does not have an equivalent. Choices must be hardcoded in the .pref YAML. This bug adds the same dynamic-source pattern to multiple_sortable so prefs needing an ordered, picker-driven multi-select of authorised values can declare: multiple_sortable: authval source: PAYMENT_TYPE Motivation: Bug 33501 (cashup amount should be configurable) needs an ordered multi-select of PAYMENT_TYPE auth values for a new CashupPaymentTypes preference. Adding it generically here means future prefs benefit too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 41197] New: opac/opac-account-pay-return.pl should not require CSRF
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41197 Bug ID: 41197 Summary: opac/opac-account-pay-return.pl should not require CSRF Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This page is intended for redirect/return from external payment vendors - they are not going to have/get a CSRF token from Koha for this. The payments are handled in a POST to the API, so this should not be a sensitive page, it just provides user confirmation. Some vendors use only a POST, we should not require CSRF on this page. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 35104] New: We should warn when attempting to save badly encoded MARC records
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104 Bug ID: 35104 Summary: We should warn when attempting to save badly encoded MARC records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 34549 Bug 34549 adds some defensive coding to prevent incorrectly encoded MARC data getting into the database.. but is does so by silently stripping bad characters from the record. It would be nice to highlight that this is taking place, or preferably before it takes place so the end user understands what's happening. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34549 [Bug 34549] The cataloguing editor allows you to input invalid data -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 357

[Bug 42719] New: OAuth/OIDC login crashes with 500 when no CGISESSID cookie exists (IdP-initiated flow)
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42719 Bug ID: 42719 Summary: OAuth/OIDC login crashes with 500 when no CGISESSID cookie exists (IdP-initiated flow) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org When a user initiates login from the IdP (e.g. clicking an app tile in Okta), they are redirected directly to Koha's /api/v1/oauth/login/{provider}/{interface} endpoint without ever visiting a Koha page first. Since no Koha page was visited, no session exists and no CGISESSID cookie is present. The code at Koha::REST::V1::OAuth::Client line 99 calls: $c->req->cookie('CGISESSID')->value This crashes with: Can't call method "value" on an undefined value The fix is to create a session on-the-fly when the initial OAuth request has no existing session cookie. This supports IdP-initiated SSO flows while preserving CSRF protection (the state parameter is still bound to the session via the browser's cookie jar). The same guard is needed on the callback branch's check_csrf call â if the cookie is missing on callback, redirect with an error instead of crashing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 39756] New: Long overdue cron configuration page
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39756 Bug ID: 39756 Summary: Long overdue cron configuration page Change sponsored?: --- 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: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Add the configuration for the long overdue cron to the Koha staff interface so that library administrators can makes changes to the long overdue cron settings without needing to use terminal commands or request assistance to do so. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|koha-bugs(a)lists.koha-commun |testopia(a)bugs.koha-communit |ity.org |y.org -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 42882] New: Add option to disable setting time and permissions for File Transports
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42882 Bug ID: 42882 Summary: Add option to disable setting time and permissions for File Transports 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Some vendors don't allow the SFTP use to change the time and permissions on uploaded files. This results in the error "Couldn't setstat remote file: General failure at /usr/share/koha/lib/Koha/File/Transport/SFTP.pm line 97." for SFTP transports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 41604] New: Impossible to hide Checkin column in issues-table in circ/circulation.pl
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41604 Bug ID: 41604 Summary: Impossible to hide Checkin column in issues-table in circ/circulation.pl 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 41314 caused a regression, making it impossible to hide the Checkin column in the issues table in the patron's circulation page. We had complaints about this following our first wave of upgrades from 24.05(.05) to 25.05(.06). To recreate: 1. Hide the checkin column by default in circulation issues-table 1.1. Go to Administration > Table settings > Circulation tab > Jump to page : circulation > Table id: issues-table 1.2. Check "Is hidden by default" for "checkin" 1.3. Click "Save" 2. Checkout an item to a patron 2.1. In the search bar, set to Checkout, search for Henry 2.2. In the checkout field, enter the barcode 39999000010114 and press enter --> In the table of issues, Checkin column is visible, it should be hidden by default I personally find the checkin column particularly dangerous as staff don't need to scan the item to return it, leading to potentially checking in items that weren't actually returned by the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 190

[Bug 34069] New: Add ability to restore a recently deleted borrower from deletedborrowers
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34069 Bug ID: 34069 Summary: Add ability to restore a recently deleted borrower from deletedborrowers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be awesome to have the ability to restore a deleted borrower from deletedborrowers. Of course, if the borrower you need has been purged from that table for whatever reason, it wouldn't work, but it feels like an essential missing feature since we keep the data for Reasons anyway. Liz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 111