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

[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

[Bug 42598] New: Spent totals on acq homepage and funds page should calculate using quantity received
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42598 Bug ID: 42598 Summary: Spent totals on acq homepage and funds page should calculate using quantity received Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The GetBudgetHierarchy sub from C4/Budgets.pm is used to calculate the Spent amount shown on the acq homepage (/cgi-bin/koha/acqui/acqui-home.pl) and the funds page in admin (/cgi-bin/koha/admin/aqbudgets.pl). This sub calculates using aqorders.quantity rather than aqorders.quantityreceived, which is not strictly accurate. It is possible to receive more items than were ordered, in which case quantity will show the number ordered while quantityreceived will show the number actually received (and therefore the number actually paid for). Note that /cgi-bin/koha/acqui/spent.pl does use quantityreceived, which will lead the two given totals to disagree. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 33756] New: Wrong calculation of total amount spent?
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33756 Bug ID: 33756 Summary: Wrong calculation of total amount spent? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am trying to work out something in acquisitions and stumbled on this bit: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Bud… # Get all the budgets totals in as few queries as possible my $hr_budget_spent = $dbh->selectall_hashref(q| SELECT aqorders.budget_id, aqbudgets.budget_parent_id, SUM( | . C4::Acquisition::get_rounding_sql(qq|COALESCE(unitprice_tax_included, ecost_tax_included)|) . q| * quantity ) AS budget_spent FROM aqorders JOIN aqbudgets USING (budget_id) WHERE quantityreceived > 0 AND datecancellationprinted IS NULL GROUP BY budget_id, budget_parent_id |, 'budget_id'); If the amount is spent, I feel multiplying by quantity is incorrect. It should be quantityreceived. I am not sure yet where this is used and how it manifests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 38256] New: Link vendors to ERM data providers
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38256 Bug ID: 38256 Summary: Link vendors to ERM data providers Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There should be the ability to link an ERM data provider to a vendor record. This will enable us to get cost data from baskets/orders and link to usage statistics -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34