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

[Bug 42120] New: Note in SIP Account setup that Institution determines logged-in library
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42120 Bug ID: 42120 Summary: Note in SIP Account setup that Institution determines logged-in library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 37893 In the new SIP interface, it would be helpful to have a tooltip or other note in the account setup page to clarify that the institution set for an account will determine which library that SIP account's circ actions are tied to. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 [Bug 37893] Migrate some SIP configuration into the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38080] New: Sorting options for holdings table are incorrect
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38080 Bug ID: 38080 Summary: Sorting options for holdings table are incorrect Change sponsored?: --- 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The sorting seems to rely on the correct ordering of the columns from the DB/YAML - the current order does not match the displayed order, so if you select to sort by CCODE, we actually sort by callnumber -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40988] New: Subfunds in acqui-home.pl and aqbudgets.pl are not collapsable beyond 20th line
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40988 Bug ID: 40988 Summary: Subfunds in acqui-home.pl and aqbudgets.pl are not collapsable beyond 20th line Change sponsored?: --- 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 When Koha renders the table of funds and subfunds for the acq homepage and the funds page in Administration, it inserts a little triangle button next to each parent fund that can be used to collapse the associated sub-funds. However, it only inserts these little buttons for parent funds within the first 20 funds returned. Beyond the 20th fund, all funds & subfunds and listed correctly but the triangle button isn't offered and subfunds cannot be collapsed. This page defaults to 20 entries per page and it looks like we're only inserting collapse buttons for what's shown at page load. If one adjusts the table to show only 10 entries, the 11th-20th parent funds will still show their collapse button successfully, but changing the number of entries to show doesn't reload the page. To recreate: - Have 20 funds, no subfunds - Add a subfund to the first fund in your list - see that the parent fund has a little triangle you can use to collapse its subfund - note that this has pushed the last fund in your list onto a second page - add a subfund to the last fund in your list - confirm this parent fund on does *not* get a little triangle button and you cannot collapse it -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 40625] New: Cashup re-submissions on page reload
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40625 Bug ID: 40625 Summary: Cashup re-submissions on page reload Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk The point of sale Cashup submission should use post/redirect/get pattern. We have been seeing duplicate cashup records and have identified that it's after an initial cashup has been performed and the user has left the page open. When they return, they reload the page (or Chrome auto-reloads it) and it performs the post again causing an empty or unexpected cashup to be recorded. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40915] New: SIP message parsing with empty fields not perfect
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40915 Bug ID: 40915 Summary: SIP message parsing with empty fields not perfect Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org SIP message parsing can create empty field values that later cause DBIx::Class constraint errors when passed to Koha operations. The current parsing logic in C4::SIP::Sip::MsgType::_initialize() doesn't provide debug logging to help identify when critical fields (patron_id, item_id) are empty, making it difficult to troubleshoot "Odd number of elements in anonymous hash" errors in SIP server logs. This includes some scenarios which cause fields to be treated as (empty) arrayrefs, which flood the logs with this kind of errors: ``` DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'itemnumber' at /usr/share/koha/lib/Koha/Objects.pm line 95 DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'borrowernumber' at /kohadevbox/koha/Koha/Objects.pm line 95 ``` -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42123] New: Add UI to test configuration sources against example call numbers
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '26

18 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42123 Bug ID: 42123 Summary: Add UI to test configuration sources against example call numbers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I was testing out the awesome bug 41932 and I realised it would be good to be able to visualise what a call number looks like when a filing rule or splitting rule is applied to it. For bug 41932 I'm doing it as a developer by writing unit tests, but it would be so handy for libraries and for people providing support to be able to just check a call number against a classification source in the web UI. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 8292] clicking ignore on hold cancels transfer
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '26

17 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8292 trevor.diamond(a)mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond(a)mainlib.org --- Comment #18 from trevor.diamond(a)mainlib.org --- We've been on Koha only since 2025, but this would be great if it could be fixed. Clicking ignore should either initiate a transfer modal or perhaps change the button to say "ignore hold and transfer item home" or something. While you can send the item without electronically tracking the transfer in Koha, this ends up with annoyed patrons who think an item is available when it's not and that same item might show up on the holds queue and staff might end up wasting time looking for an item that's on the delivery truck. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42117] New: Plugin Search should warn of minimum Koha version
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '26

17 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42117 Bug ID: 42117 Summary: Plugin Search should warn of minimum Koha version Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jvinke(a)austinseminary.edu QA Contact: testopia(a)bugs.koha-community.org The plugin Search and install feature does not warn users that they are about to install a plugin for a newer version of Koha. Several of us learned this during the Koha-US Acquisitions SIG when we went to update our plugins only to be greeted with the following message after doing so: "Warning: This plugin was written for a newer version of Koha. Use at your own risk." At the bare minimum, it seems that the search results should include a column letting you know what version of Koha the plugin was written for. Maybe even better if it would not show you versions that are for newer versions of Koha that you are on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42082] New: Add access to issues and transactions data to "patrons custom message" notice
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '26

17 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42082 Bug ID: 42082 Summary: Add access to issues and transactions data to "patrons custom message" notice Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbcornell(a)cityofportsmouth.com QA Contact: testopia(a)bugs.koha-community.org Bug 29393 added the ability to define custom notices that can be sent from the patron account page. Bug 40426 proposes that the "patrons (custom message)" notice should have access to ILL data. In addition to that, it should have access to issues and transactions data. Our initial uses would be to send a patron summary or an issue slip via email. This would be in addition to adding SMS support which is requested in bug 40933. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

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

17 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #458 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 195595 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195595&action=e… Bug 10190: Fix false conflict error when editing specific trigger rules When editing a specific rule (e.g. */Kids/Books) alongside an all/all/all rule, the conflict check incorrectly reported a conflict. The effective=true API response always returns context as */*/* (fallback), so ruleSetInDb.context differed from currentRuleSet.context (which was overridden to the real context). Fix by overriding ruleSetInDb.context before the hasConflict comparison, consistent with the existing pattern in setCurrentRuleSet. -- You are receiving this mail because: You are watching all bug changes.

1 0