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

[Bug 42055] New: Real time holds queue doesn't rebuild when hold from group hold is filled
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42055 Bug ID: 42055 Summary: Real time holds queue doesn't rebuild when hold from group hold is filled Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library is using the real-time holds queue and a hold that is part of a group hold/hyperhold is filled, the queue isn't rebuilt to remove the other titles. To replicate: -Make sure library is using the real-time holds queue. -Create a group hold with multiple items available at one or more libraries. -Note that all available titles show on the holds queue(s) (see bug 42054). -Check an item in to satisfy the hold group. -Re-run the holds queue(s), and note that the other items from the group hold still show. The queue only appears to rebuild once the item that filled the hold is checked out. If a library checks one of the other items from the group in after the hold has been filled, the later item(s) won't trigger. This is correct behavior, but the fact that the other titles from the group still show on the queue is likely to cause significant frustration and confusion for libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 42897] New: FilterSearchResultsByLoggedInBranch display should expand and collapse
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42897 Bug ID: 42897 Summary: FilterSearchResultsByLoggedInBranch display should expand and collapse Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- With the new system preference FilterSearchResultsByLoggedInBranch, it would be nice to be able to expand and collapse the view of all holdings at all locations without needing to keep toggling between show items in all libraries and show local items only. When defaulting to show items in all libraries, a popular title with many copies or a magazine like People with many issues and copies can take up most of the screen of search results. Having an expand/collapse display of holdings across the system per bib record in the results would be ideal. For example, A court of thorns and roses large print edition has 2 copies available at the logged in branch, which show in the location column. There are 27 other copies, which show when clicking on an expand button for that bib in the search results. Clicking the button again collapses the results back to the two at the logged in branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 35934] New: Items in transit show as both in-transit and Available on holdings list
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35934 Bug ID: 35934 Summary: Items in transit show as both in-transit and Available on holdings list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 35696 Like bug 35696, this is another missed case where items.transfer should have been switched to transfer in the template. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35696 [Bug 35696] Transit status not properly updated for items advanced in Stock Rotation tool -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 43400] New: Add granularity to AllowHoldCheckoutOverride
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43400 Bug ID: 43400 Summary: Add granularity to AllowHoldCheckoutOverride Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 23909 Target Milestone: --- With the updates to AllowItemsOnHoldCheckoutSIP and AllowItemsOnHoldCheckoutSCO from bug 23909, administrators can now choose whether patrons can check out items with pending holds, or pending *and* waiting holds, or neither via SIP and SCO. However, the new AllowHoldCheckoutOverride system preference only has options for 'Allow' and 'Don't allow' without any distinction between allowing override of pending holds vs. waiting holds. This means that there is less flexibility in policy for staff who are checking items out to patrons than for patrons who check out via SIP and SCO. It would be helpful if AllowHoldCheckoutOverride had the same options for *types* of holds that can be overridden that now exist for AllowItemsOnHoldCheckoutSIP and AllowItemsOnHoldCheckoutSCO so that policies can be aligned no matter how patrons are checking out items. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 [Bug 23909] SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36713] New: Show bibliographic information of deleted records in acquisition invoices
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36713 Bug ID: 36713 Summary: Show bibliographic information of deleted records in acquisition invoices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Similar to bug 10758, but for acquisition invoices. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43381] New: Report row count query ( nb_rows ) ignores report_sql_max_statement_time_seconds
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43381 Bug ID: 43381 Summary: Report row count query ( nb_rows ) ignores report_sql_max_statement_time_seconds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- Bug 39164 added report_sql_max_statement_time_seconds, which wraps report SQL in a SET STATEMENT max_statement_time so the database kills a runaway report. It works for the query that fetches the results, but not for the query that counts them. C4::Reports::Guided::execute_query() applies the limit to its own copy of the SQL, so the caller's copy is untouched. reports/guided_reports.pl then hands that original SQL to nb_rows(), which runs SELECT COUNT(*) FROM $sql with no time limit. If that wrapper fails ( e.g. "Duplicate column name" ), nb_rows falls back to running the report a second time and counting every row by hand, also with no limit. Test Plan: 1) Apply the first patch 2) prove t/db_dependent/Reports/Guided.t 3) Note the 'nb_rows() tests' subtest fails! 4) Apply the remaining patches 5) prove t/db_dependent/Reports/Guided.t 6) Note the tests pass now! 7) Add this to koha-conf.xml: <report_sql_max_statement_time_seconds>2<report_sql_max_statement_time_seconds> 8) Restart all the things! 9) Create a report with the SQL: SELECT b1.borrowernumber FROM borrowers b1, borrowers b2 WHERE SLEEP(0.005) = 0 10) Run the report 11) Note the page comes back in about 2 seconds, the first 20 rows are shown, and "Total number of results" is *not* displayed! 12) Comment out report_sql_max_statement_time_seconds in koha-conf.xml 13) Restart plack again 14) Run the report again 15) Note the page now takes about 20 seconds and "Total number of results" is displayed! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 24401] New: REST API: Check-in
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 Bug ID: 24401 Summary: REST API: Check-in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 124

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28