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

[Bug 43237] New: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43237 Bug ID: 43237 Summary: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39698 Target Milestone: --- With the responsive tables introduced by Bug 39698, the Course Reserves table has an 'Expand' column header for the column with the '+' button, but others tables I've observed do not. All of them should have the 'Expand' header. Tables without the Expand header include: Holdings Patron's current checkouts Patron's current holds Patron's clubs Patron's checkout history Patron's search history Patron's charges (That list may not be exhaustive as I've only noted the tables that I've found are responsive.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39698 [Bug 39698] Add option to expand responsive datatable rows by default -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 43582] New: Allow Vue API clients to opt out of the shared HttpClient's generic error banner
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43582 Bug ID: 43582 Summary: Allow Vue API clients to opt out of the shared HttpClient's generic error banner 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- The shared Vue HttpClient (koha-tmpl/intranet-tmpl/prog/js/vue/fetch/http-client.js) unconditionally calls the global setError() helper on any failed API request (see _fetchJSON's .catch(err => { error = err; setError(err); })), showing a generic "Something went wrong: <raw error>" banner regardless of whether the calling component already handles and displays the error itself. This means any Vue component that wants to show its own friendly, translated, context-specific error message ends up showing BOTH the generic banner and its own message for the same failure. This was noticed while testing bug 35837 (Plugin store): a failed plugin install shows both "Something went wrong: Error: SIGNATUREMISMATCH" (global, raw error code) and "This file's signature doesn't match what the store signed -- it may have been altered or corrupted." (local, friendly translated message) at the same time, for the same failure. At least one existing component (RecordSourcesResource.vue) works around this today by supplying an empty local error handler and relying solely on the global banner -- but that means a component can't have both structured/friendly local messaging AND suppress the redundant generic one. This bug proposes adding an opt-out parameter to HttpClient's request methods (get/getAll/post/postForm/etc, threaded through to _fetchJSON) so a caller that's already going to display its own error message can skip the automatic global setError() call for that request, instead of duplicating the message on screen. Test plan: 1. Pick a Vue component that calls a REST endpoint and currently shows its own local error message on failure (e.g. the Plugin store install flow from bug 35837, once landed, triggering a SIGNATUREMISMATCH or similar 403). 2. Confirm today both the generic "Something went wrong: ..." banner and the component's own local error message are shown together. 3. Apply this enhancement's patch and have the component pass the new opt-out flag on its API call. 4. Confirm only the component's own local error message is shown, with no duplicate generic banner. 5. Confirm other, unrelated Vue components that do NOT pass the new flag are unaffected and still show the generic banner as before. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40990] New: Checkout override allowed without permissions when item has circulation alert
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40990 Bug ID: 40990 Summary: Checkout override allowed without permissions when item has circulation alert Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Koha will allow staff who do not have force_checkout permissions to check out items beyond the maximum number per type allowed if the item has a circulation alert. In this case a warning is offered but staff can click to continue with the checkout. This behavior is different than when items do not have the circulation alert ; in that case the same staff hit a hard block and cannot override the limitation. This may be related to bug 38540. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38540] New: Checkout override allowed without permissions when item has parts / materials specified
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38540 Bug ID: 38540 Summary: Checkout override allowed without permissions when item has parts / materials specified Change sponsored?: --- 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.m.hall(a)gmail.com Koha will allow a user who does not have force_checkout permissions to check out to a user with fines over the NoIssuesCharge amount if the item to be checked out has a value in items.materials has content. To confirm: 1- set AllowFineOverride to Allow, confirm there is a value in NoIssuesCharge 2- have a user with circulate_remaining_permissions but not force_checkout 3- have a patron with fines over the NoIssuesCharge amount 4- have two items: Item A does not have a value in items.materials, Item B does 5- log in as your user, find your patron 6- attempt to check Item A out to your patron, Koha tells you "Cannot check out" and "Patron has a debt" 7- attempt to check out Item B, Koha says "Please confirm checkout," tells you about the debt and the materials note This happens whether or not CircConfirmItemParts is on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 30894] New: Add ability to select all/clear all and delete selected label batches
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30894 Bug ID: 30894 Summary: Add ability to select all/clear all and delete selected label batches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When managing label batches (label-manage.pl) it would be handy to be able to select all/clear all label batches. It would also be nice if you could delete all selected batches instead of having to go through your batches and delete them one at a time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7386] Label batches cannot be batch deleted
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7386 Marie-Luce Laflamme <marie-luce.laflamme(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marie-luce.laflamme@inlibro | |.com --- Comment #9 from Marie-Luce Laflamme <marie-luce.laflamme(a)inlibro.com> --- It would be a huge help if we could delete multiple batch labels. Someone else as mentioned this improvement in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30894 and adding an option in the cleanup.database script https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31969. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43296] New: Circulation statistics do not work with non-numeric patron attribute codes
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43296 Bug ID: 43296 Summary: Circulation statistics do not work with non-numeric patron attribute codes 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: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42735 Target Milestone: --- Bug42735 restricted patron attribute codes in circulation statistics to numeric values. Existing attributes with alphanumeric codes, such as SHOW_BCODE, no longer pass validation. When selected as a row, Koha silently falls back to branch and produces incorrect statistics. When selected as a column, Koha falls back to datetime and may fail with a datetime isn't in GROUP BY DBI error. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42735 [Bug 42735] [CVE-2026-70373] SQL Injection in reports/issues_stats.pl via PeriodTypeSel / PeriodDaySel / PeriodMonthSel / Filter parameters (unvalidated string context, no placeholders) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 42250] New: Add link from patron page to hold batch modification tool
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42250 Bug ID: 42250 Summary: Add link from patron page to hold batch modification tool Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 36135 It would be really handy to be able to select holds on the patron page and send them straight to the hold batch modification tool. For example, we may want to change the pickup location on all of a patron's holds if they move. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36135 [Bug 36135] Add tool to batch modify holds -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41129] New: Migrate place_booking.js to a Vue island.
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 Bug ID: 41129 Summary: Migrate place_booking.js to a Vue island. 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Since the bookings functionality requires a significant amount of reactivity due to many interdependent inputs to achieve a good UX, this bug is intended to deprecate place_booking.js in favor of a Vue island that makes this much easier. The goal here is to have a Vue based component that is used for the Staff Interface as well as the OPAC to avoid duplication and diverging implementations and also makes it easier to keep track of problems that then don't need to be fixed in two places. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 304

[Bug 43375] New: OAuth userinfo_url silently fails to parse JSON when Content-Type has extra parameters (e.g. Microsoft Graph)
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Bug ID: 43375 Summary: OAuth userinfo_url silently fails to parse JSON when Content-Type has extra parameters (e.g. Microsoft Graph) 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 Target Milestone: --- When configuring an OAuth Identity Provider whose userinfo_url points to an endpoint that returns a Content-Type header with parameters other than charset (for example, Microsoft Graph API's /v1.0/me, which returns Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8), Koha::Auth::Client::OAuth::_get_data_and_patron fails to parse the response as JSON and silently falls back to treating the body as URL-encoded form data, resulting in all mapped fields being undef â even though the HTTP request succeeded (200) and the body is valid JSON. Root cause: the content-type check at Koha/Auth/Client/OAuth.pm line 86 is a strict regex that only accepts application/json or text/javascript optionally followed by a single ;charset=... parameter: $tx->res->headers->content_type =~ m!^(application/json|text/javascript)(;\s*charset=\S+)?$! Any additional parameter (common in OData-based APIs like Microsoft Graph) causes this regex to fail, silently routing the response through Mojo::Parameters->new($body)->to_hash instead of $tx->res->json. No error or warning is logged â from the admin's perspective, the identity provider config looks correct, the external IdP call succeeds, but login fails downstream with a generic 'No configuration found for your email domain' or 'External auth user cannot access resource' error. Steps to reproduce: 1. Configure an OAuth Identity Provider with userinfo_url pointing to https://graph.microsoft.com/v1.0/me (with an appropriate User.Read scope and a valid Azure AD/Entra ID app). 2. Map any field (e.g. userid -> onPremisesSamAccountName). 3. Attempt to log in via this provider. 4. Observe the login fails to find/match a patron, despite the Graph API call itself succeeding with correct data. Suggested fix: Relax the content-type check to accept any parameters after the media type, not just charset: $tx->res->headers->content_type =~ m!^(application/json|text/javascript)(;|$)! Test plan: 1. Apply the patch. 2. Run: prove t/db_dependent/Koha/Auth/Client/OAuth.t => SUCCESS (new subtest covering extra content-type parameters passes) 3. Configure an OAuth provider with Microsoft Graph userinfo_url. 4. Verify login works when the response includes extra Content-Type parameters. => SUCCESS -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16