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

[Bug 43844] New: Checked-out item with a biblio-level hold can be put as waiting
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43844 Bug ID: 43844 Summary: Checked-out item with a biblio-level hold can be put as waiting 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: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In Koha, an item that is checked out cannot at the same time be "waiting for pickup" for a hold: the item has to be physically back at the library before it can be put aside for the patron. However, a librarian can put an item that is already issued to another patron — and that has a hold — into the "waiting for pickup" state. This is not a race condition: the item was already issued when the librarian confirmed the hold. Steps to reproduce ================== 1. Create a biblio with one item. Check the item out to patron A. 2. Place an item-level hold on that item for patron B (pickup at the same library). 3. Go to Circulation, scan patron B's card, then scan the item's barcode. 4. The checkout screen shows that the item is issued to another patron and, because of the hold, also offers "Don't check out, confirm hold, and print slip". 5. Click "Confirm hold". 6. Open patron B's account and look at the Holds tab. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 Frédéric Demians <f.demians(a)tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43843 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43843 [Bug 43843] OPAC JavaScript translations break when the Content-Security-Policy is enabled -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43842] New: Circulation Triggers is not included in Administration sidebar menu
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43842 Bug ID: 43842 Summary: Circulation Triggers is not included in Administration sidebar menu Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 Depends on: 10190 Target Milestone: --- The new Circulation Triggers page is not included in the sidebar menu when one is in another page within Administration. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 [Bug 10190] Overdue notice triggers based on item type -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43842 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43842 [Bug 43842] Circulation Triggers is not included in Administration sidebar menu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43245] New: When sending a reset email, there should be a message if no email was provided
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43245 Bug ID: 43245 Summary: When sending a reset email, there should be a message if no email was provided Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 42625] New: Allow records to be locked for editing based on library & group
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42625 Bug ID: 42625 Summary: Allow records to be locked for editing based on library & group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 31791 established record locking based on record source. We'd like to extend that to allow records to be locked for some users based on library and library group. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 191

[Bug 23054] New: Unable to change priority after reverting hold waiting status
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Bug ID: 23054 Summary: Unable to change priority after reverting hold waiting status Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 Target Milestone: --- To Test: - Place a hold for Patron A - Place a hold on same item for Patron B - Check item in, triggering Patron A's hold - Revert waiting status on hold - Confirm holds list shows Patron A at priority 1, Patron B at priority 2 - Use arrow buttons to move Patron B to priority 1 - Query reserves table to confirm Patron B at priority 1, Patron A at priority 2 - Check item in - Patron A's hold triggers, even though Patron B was first in priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43570] New: Memory leark in SafeURL abd HtmlScrubber Template::Toolkit filters
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43570 Bug ID: 43570 Summary: Memory leark in SafeURL abd HtmlScrubber Template::Toolkit filters Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Right now every request that renders a page using SafeURL or HtmlScrubber leaks the entire template context. It seems to be around 7 to 13 MB per request depending on the page ( almost 8 MB on opac-detail, 11 on circulation.pl, and 13 on moremember.pl ). This memory doesn't get released at the end of the request because the context points to the filter, and the filter points to the context. The reason it hurts so much is what the context is. It's the root of the whole render. Every compiled template, the stash, and everything the stash was holding. On opac-detail.pl that's the Koha::Biblio, the MARC::Record and all the compiled templates. So one stuck context drags a whole page's worth of stuff along with it, and then we do it again on the next request, and the next. This is actually a known issue in TT 2.20+ and was done on purpose: # This causes problems: https://rt.cpan.org/Ticket/Display.html?id=46691 # If the plugin is loaded twice in different templates (one INCLUDEd into # another) then the filter gets garbage collected when the inner template # ends (at least, I think that's what's happening). So I'm going to take # the "suck it and see" approach, comment it out, and wait for someone to # complain that this module is leaking memory. # weaken($this); The call to weaken() was restored in TT 3.1, and they weaken _CONTEXT rather than the plugin itself, which is the same thing my patch will do. -- You are receiving this mail because: You are watching all bug changes.

1 30

[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 16 Oct '26

16 Oct '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 18

[Bug 43373] New: Holdings table always displays the shelving location column
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43373 Bug ID: 43373 Summary: Holdings table always displays the shelving location column Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Shelving location is always displayed because it unconditionally wraps the output in: ``` let nodes = '<span class="shelvingloc">'; ... nodes += "</span>"; return nodes; ``` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10