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

[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 42330] New: Use main-container.inc from all the templates
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42330 Bug ID: 42330 Summary: Use main-container.inc from all the templates Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We can now use main-container.inc with a custom aside (see bug 42322). Now we need to use it for all our templates. -- You are receiving this mail because: You are watching all bug changes.

1 87

[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

[Bug 42385] New: Extract _GetCircControlBranch into Koha::Policy::Circulation
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 Bug ID: 42385 Summary: Extract _GetCircControlBranch into Koha::Policy::Circulation 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: 41728 _GetCircControlBranch is a private function in C4::Circulation that is exported (the code itself comments "This is wrong!") and used from Koha::Item, Koha::Recall, and multiple places in C4::Circulation. It resolves which library controls circulation rules given the CircControl and HomeOrHoldingBranch system preferences. This is the exact same pattern as Koha::Policy::Holds->holds_control_library, which resolves the controlling library for hold rules based on ReservesControlBranch. This bug proposes: - Add Koha::Policy::Circulation with a circ_control_library($item, $patron) class method - Replace all _GetCircControlBranch calls with the new method - Remove the exported private function from C4::Circulation - Add unit tests This is a prerequisite for the checkout availability work, as the future Koha::Item::Checkout::Availability class would need to resolve the controlling library. Referenced Bugs: 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 41

[Bug 30319] New: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30319 Bug ID: 30319 Summary: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a field is hidden for self-registration, Koha is mistakenly discarding values for that field in self-modification. Somehow these two sysprefs are not being enforced distinctly. To test: 1 - turn on OPACPatronDetails 2 - confirm PatronSelfModificationBorrowerUnwantedField is blank, all fields allowed 3 - set PatronSelfRegistrationBorrowerUnwantedField to hide Title 4 - log into the opac, go to self mod (/cgi-bin/koha/opac-memberentry.pl), set a title (it is not hidden, which is correct), and save your updates 5 - go to the patron modification page in the staff interface (/cgi-bin/koha/members/members-update.pl), confirm your modification request is there but shows no changes 6 - update PatronSelfRegistrationBorrowerUnwantedField to allow title 7 - repeat step 4 8 - your new modification request shows a change to title -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 38666] New: New feature: closed stack requests
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38666 Bug ID: 38666 Summary: New feature: closed stack requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A closed stack request is a special kind of hold that can only be placed on a closed stack item. A closed stack item is an item that is not available publicly in the library but can be made available on demand. When a request is made, a librarian will print a slip then will go retrieve the document and place the slip in place of the document. -- You are receiving this mail because: You are watching all bug changes.

1 86

[Bug 42824] New: [OMNIBUS] Permissions in need of documentation
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42824 Bug ID: 42824 Summary: [OMNIBUS] Permissions in need of documentation Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Target Milestone: --- Some staff permissions seem to have been missed in the Koha Manual section at https://koha-community.org/manual/latest/en/html/patrons.html#patron-permis… Each permission added should also be mentioned in the relevant section for the feature it relates to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42822] New: Perform batch modification of holds permission needs documentation
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42822 Bug ID: 42822 Summary: Perform batch modification of holds permission needs documentation Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Target Milestone: --- This permission is not currently documented. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42583] New: Batch modify holds job should be able to revert hold statuses
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42583 Bug ID: 42583 Summary: Batch modify holds job should be able to revert hold statuses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com In the case of a library having a closure for whatever reason (emergency, plumbing, planned construction) it would be helpful to be able to reset/update any holds that are waiting/in-transit. Adding the option to revert statuses when modifying would greatly reduce the amount of work needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 42249] New: Wrong body id on 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=42249 Bug ID: 42249 Summary: Wrong body id on hold batch modification tool Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36135 The hold batch modification page has the body id "tools_batch_extend_due_dates". 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 the assignee for the bug. You are watching all bug changes.

1 1