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

[Bug 5276] subscription end date shouldn't be required / allow indefinite subscriptions
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5276 Adam Harris <aharris(a)capecod.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aharris(a)capecod.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41512] New: ILLCheckAvailability stage table doesn't render
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41512 Bug ID: 41512 Summary: ILLCheckAvailability stage table doesn't render Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 40856] New: Improve Standard backend metadata retrieval
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40856 Bug ID: 40856 Summary: Improve Standard backend metadata retrieval Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The metadata() method in the Standard ILL backend uses an inefficient pattern for filtering attributes, performing a linear search through an ignore list for every attribute using grep inside a while loop. This approach becomes increasingly slow as the number of attributes grows, and manually iterates through all attributes instead of leveraging database-level filtering. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40855] New: Standard backend uses plain SQL
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40855 Bug ID: 40855 Summary: Standard backend uses plain SQL Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The edititem() method in the Standard ILL backend uses raw SQL queries with manual delete-all-and-recreate patterns instead of leveraging Koha's ORM. This approach creates several problems: it bypasses ORM validation and relationships, uses inefficient delete-all-then-insert operations that update unchanged attributes, includes complex conditional SQL based on column existence checks [1], and makes the code harder to maintain and debug. The method contains over 40 lines of raw SQL that could be replaced with a single call to add_or_update_attributes() (from bug 40850), which would be more efficient (only updating changed values), safer (using ORM validation), more maintainable (no raw SQL). [1] For backwards compatibility with older Koha versions? Inherited from the time it was an external backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41009] New: When editing an ILL request, the user is returned to the list
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41009 Bug ID: 41009 Summary: When editing an ILL request, the user is returned to the list Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com It should return to the request. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 31215] New: Add ability to select multiple items to remove from course_items
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31215 Bug ID: 31215 Summary: Add ability to select multiple items to remove from course_items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the only way to remove items from course reserves is to remove all reserves or select items individually to remove. For libraries that use course reserves with large courses, the ability to select multiple items at a time to remove would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42013] New: Confirmation dialog for "Remove all reserves" never shown on course details page
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42013 Bug ID: 42013 Summary: Confirmation dialog for "Remove all reserves" never shown on course details page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org On the course details page (course_reserves/course-details.tt), clicking "Remove all reserves" skips the confirmation dialog and immediately submits the form. The "Remove all reserves" button (#rm_items_button) is an <a> tag separate from the #rm_items form. The click handler on the button calls $("#rm_items").submit() programmatically. A separate $("#rm_items").click(...) handler was intended to show a confirmDelete dialog, but it is bound as a click event on the form element, which is never clicked by the user. jQuery's .submit() method also does not trigger click events, so the confirmation is never shown. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 22707] New: Allow manual definition of AutoMemberNum range
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22707 Bug ID: 22707 Summary: Allow manual definition of AutoMemberNum range Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Target Milestone: --- It'd be great to have a way to tell Koha where to start when assigning card numbers via AutoMemberNum and to see what the next number will be. Bug 19263 introduced a feature that uses an authorized value to set up ranges of auto-incremented control numbers in bib records. Could something similar be used for card numbers? Ideally, this could also allow the definition of separate card number ranges for different branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 42762] New: Click on quantity will decrease quantity even the number of items increased on neworderempty
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42762 Bug ID: 42762 Summary: Click on quantity will decrease quantity even the number of items increased on neworderempty Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org - on a new ktd go to /cgi-bin/koha/acqui/neworderempty.pl?booksellerid=1&basketno=1 (Acquisitions -> Search Vendors -> My Vendor -> Baskets -> My Basket -> Add to basket -> From a new (empty) record - enter a title and koha item type - add item - select a fund and save - in the orders table click modify on the just created order - add another item - then click in the quantity field, which is read only. Click outside. - notice the alert 'You can't add a new item, please create a new order line' - quantity is reset to 1 even though the items list on top shows 2 items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

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

03 Jun '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 16