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

[Bug 43347] New: Simple OPAC search with no results generates warnings: Odd number of elements in anonymous hash
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43347 Bug ID: 43347 Summary: Simple OPAC search with no results generates warnings: Odd number of elements in anonymous hash Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We repeat a search with no results with the terms quoted - this second possible search didn't get the same fix from bug 41864 -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41864] New: Simple OPAC search generates warnings: Odd number of elements in anonymous hash
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41864 Bug ID: 41864 Summary: Simple OPAC search generates warnings: Odd number of elements in anonymous hash Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 40966 After introducing Bug 40966 opac-search.pl, when invoked in the simple form (not as advanced search) generates warnings like: [WARN] Odd number of elements in anonymous hash at /kohadevbox/koha/opac/opac-search.pl line 529. This is because 'weight_search_submitted' is not initialized for this search. You get the same effect with this simple test: #!/usr/bin/perl use Modern::Perl; use Data::Dumper; say Dumper( { one => 1, two => &und } ); sub und { #return undef; } But if you uncomment 'return undef', there is no warning. So most probably, in this case, $cgi->param('weight_search_submitted') returns an empty list, not an undef. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40966 [Bug 40966] 'whole_record' and 'weighted_fields' not passed around -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 37671] New: Can't print receipt for refund from cash register transaction history
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37671 Bug ID: 37671 Summary: Can't print receipt for refund from cash register transaction history Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com ERROR PROCESSING TEMPLATE: undef error - Exception 'Koha::Exceptions::Account::IsNotCredit' thrown 'Account line 321 is not a credit' at /kohadevbox/koha/pos/printreceipt.pl line 54. at /usr/lib/x86_64-linux-gnu/perl-base/Carp.pm line 289 1. Make a purchase through Point of Sale. 2. Go to the transaction history for the register you used. 3. Issue a refund for the purchase. 4. Click the "Print receipt" button for that refund. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 68

[Bug 39802] New: Add CircControl equivalent system preference for lost item fees and actions
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39802 Bug ID: 39802 Summary: Add CircControl equivalent system preference for lost item fees and actions Change sponsored?: --- 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 9596 Blocks: 36506 We need something like CircControlLostBranch with which to specify which branch should be followed for actions and fees related to lost items. Since Bug 9596 the longoverdue cron can be limited by branch, but it follows CircControl when doing so. Lost item fee and processing fee refunds also follow CircControl. However, some libraries want checkout limits and periods to be governed by issuing branch but lost item behavior to be based on the owning library of the item. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9596 [Bug 9596] Allow longoverdue.pl to be configured per library on the command line https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36506 [Bug 36506] Processing Fee should be configurable by branch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 37966] New: When overriding a hold to renew a book the due date becomes "now" of not specified
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37966 Bug ID: 37966 Summary: When overriding a hold to renew a book the due date becomes "now" of not specified Change sponsored?: --- 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: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In circ/renew.pl, when trying to renew a book, if the book is on hold the override dialog is presented. If the 'renewonholdduedate' field is left empty, then the due date ends up being "now". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 41749] New: Add patron consent status display to staff patron detail page
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41749 Bug ID: 41749 Summary: Add patron consent status display to staff patron detail page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 31503 Currently, staff members have no visibility into what consents a patron has given or refused. The consent management exists only in the OPAC (opac-patron-consent.pl), where patrons can manage their own consent preferences for GDPR and plugin-defined consent types (added in bug 31503). This creates a gap in staff workflows - when assisting patrons or reviewing accounts, staff cannot see whether a patron has consented to privacy policies or other consent types defined by plugins. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31503 [Bug 31503] Allow several consent types on the consents tab of OPAC account page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 41674] New: Add template plugin for linking to system preferences based on user permission
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41674 Bug ID: 41674 Summary: Add template plugin for linking to system preferences based on user permission 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: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There are many places in templates where we link to a system preference and we are inconsistent about whether these links are dependent on the permission of the logged-in user. I propose to add a template plugin which handles the permission check. [% "RequireChoosingExistingAuthority" | html | $LinkPref %] For a user with 'CAN_user_parameters_manage_sysprefs' permission it outputs: <a class="link_preference" href="admin/preferences.pl?op=search&ok=Search&searchfield=RequireChoosingExistingAuthority">RequireChoosingExistingAuthority</a> For a user without permission it outputs: <span class="link_preference">RequireChoosingExistingAuthority</span> -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 43257] New: Remove event attributes from circulation.tt
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43257 Bug ID: 43257 Summary: Remove event attributes from circulation.tt Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 38407 Target Milestone: --- circulation.tt has a couple of "onclick" event attributes which should be moved to checkouts.js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43344] New: OPAC does not show the On order item status when acquisition details are enabled
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43344 Bug ID: 43344 Summary: OPAC does not show the On order item status when acquisition details are enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36018 Target Milestone: --- When OPACAcquisitionDetails is enabled, the OPAC checks active acquisition orders for each item. For an item linked to an outstanding order, this check logs the following SQL error: Unknown column 'me.quantity' in 'WHERE' The order count returns no value, so the item is not displayed with the On order status. Steps to reproduce: 1. Set OPACAcquisitionDetails to Show. 2. Set AcqCreateItem to create an item when placing an order. 3. Create a basket and add an order for a bibliographic record, including an item. 4. Close the basket so the order is active and outstanding. 5. Open the bibliographic record in the OPAC. Expected result: The item is displayed with the On order status and no SQL error is logged. Actual result: The On order status is not displayed and the SQL error is logged. Technical note: item-status.inc calls item.orders.filter_by_active.count. item->orders is a many-to-many DBIx::Class resultset whose current source alias is ordernumber. filter_by_active hard-codes me.quantity, so the generated SQL refers to an alias that is not present in this query. This was introduced by the Bug 36018 follow-up that qualified quantity to avoid ambiguity in REST API joins. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36018 [Bug 36018] Improve consistency in Acquisition/Order(s) regarding active/current orders -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 43345] New: The Pending orders table lists order lines with a cancellation date
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '26

20 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43345 Bug ID: 43345 Summary: The Pending orders table lists order lines with a cancellation date 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: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36018 Target Milestone: --- The Pending orders table can list historical order lines whose cancellation date is set while their status is still new, ordered or partial and an outstanding quantity remains. Bug 36018 made the Pending orders table use Koha::Acquisition::Orders->filter_by_active. The filter checks order status and outstanding quantity, but it does not check datecancellationprinted. Bug 36068 classifies this exact combination (a cancellation date with a non-cancelled status) as obsolete acquisition data. As a result, an obsolete cancelled order line can be offered for receiving. Steps to reproduce: Prerequisite: use an upgraded test database containing an old order line with a cancellation date, status new, ordered or partial, and an outstanding quantity. Keep a normal outstanding order for the same vendor as a control. 1. Go to Acquisitions. 2. Open the vendor used by the two order lines. 3. Click "Receive shipments". 4. Create or open an invoice. 5. Look at the Pending orders table. Actual result: The obsolete order line with a cancellation date is listed together with the normal outstanding order. Expected result: The order line with a cancellation date is not listed. The normal outstanding order remains available for receiving. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36018 [Bug 36018] Improve consistency in Acquisition/Order(s) regarding active/current orders -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4