December 2025 - Koha-bugs - lists.koha-community.org

[Bug 41374] New: Display "create items when" in general basket information
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41374 Bug ID: 41374 Summary: Display "create items when" in general basket information Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 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 CC: esther.melander(a)bywatersolutions.com Moved from bug 33660: It would be nice if the "Create items when" displayed in the General information about the basket. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41168] New: "Search the catalog by keyword" confuses some users
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41168 Bug ID: 41168 Summary: "Search the catalog by keyword" confuses some users Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org We got some questions about this new test from masthead on the OPAC search bar. Like: Can I only use keywords now? I would propose to remove the phrase "by keyword" here. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 30633] New: Move OPACHoldingsDefaultSortField to table settings configuration
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30633 Bug ID: 30633 Summary: Move OPACHoldingsDefaultSortField to table settings configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 29648 Now that the sorting of a table can be defined in administration > table settings, we should move OPACHoldingsDefaultSortField there and remove the pref. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29648 [Bug 29648] Make KohaTable tables 'default length' and 'default sort' configurable -- You are receiving this mail because: You are watching all bug changes.

1 61

[Bug 41372] New: Preservation/Settings.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41372 Bug ID: 41372 Summary: Preservation/Settings.ts is failing Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There is a warning in the console: > JS Warning detected: "[Vue warn]: Unhandled error during execution of setup function" "\n" " at <RouterLink" "key=1" "to=\"/cgi-bin/koha/preservation/settings/processings\"" ">" "\n" " at <NavigationItem" "key =0" "item=" [object Object] "params=" {} ">" "\n" " at <Breadcrumbs>" "\n" " at <App>" -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 9810] Search limit 'available' does not hide damaged, withdrawn, or not-for-loan items
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9810 Katie Bliss <kebliss(a)dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss(a)dmpl.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40743] New: Unable to select the correct fund when paying invoices.
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40743 Bug ID: 40743 Summary: Unable to select the correct fund when paying invoices. Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: tgoatley(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 186059 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186059&action=e… Display of order edit We are an early adopter to 25.05.02 and we're unable to select the correct fund when paying invoices. This refers to paying paper invoices we receive since as this Baker &Taylor example. Previously, we were given the option to select the fund, and since we have two active funds now due to closing out the fiscal year, we are only able to see one of the active funds (unfortunately not the fund we need to pay this invoice). I checked acquisitions permissions, and Sandra has full ACQ permissions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 41370] New: Auto renewal error auto_too_much_oweing should not take precedence over too_many
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41370 Bug ID: 41370 Summary: Auto renewal error auto_too_much_oweing should not take precedence over too_many Initiative type: --- Sponsorship --- status: 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: raina(a)flo.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If an item is scheduled for automatic renewal and has already renewed the maximum number of times allowed, and the patron has NO fines that could block a renewal, then the error at the next attempted renewal is "too_many." However, if an item is scheduled for automatic renewal, has already renewed the maximum number of times allowed, and the patron has fines exceeding the amount allowed for automatic renewals, then the error at the next attempted renewal is "auto_too_much_oweing". This causes issues if a library wants to use the auto_renewals_dgst notice to let patrons know if a renewal failed because of fines. If an item has an automatic renewal left but it is blocked because of fines, then the library may want to let the patron know about those fines in the notice, so they can address them. However, if the item has no renewals left, becomes long overdue and the patron is charged for the item cost, and is still is not returned, every time auto renewal is attempted the error will continue to be "auto_too_much_oweing." If an item has been renewed the maximum number of times, the error should be "too_many" regardless of if there are fines that could prevent a renewal. To re-create: - Circ rules allow one automatic renewal for set patron group and item type - Set OPACFineNoRenewalsBlockAutoRenew to Block renewals if patron owes more than amount defined in OPACFineNoRenewals. OPACFineNoRenewals should be >0 amount. - Check out item to patron and renew once successfully. The item should be "scheduled for auto renewal" but have no renewals left. - Manually charge fine greater than OPACFineNoRenewals to patron. - Making sure loan is within range of attempting auto renew again via circ rule, run automatic_renewals script to trigger automatic renewal attempt. Error is auto_too_much_oweing. - Repeat the steps but without putting a fine on the patron's account, and error is too_many. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41365] New: objects.search_rs puts too much pressure on the DB
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41365 Bug ID: 41365 Summary: objects.search_rs puts too much pressure on the DB Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Found in the wild while analyzing a performance issue on a very big partner site. ```shell perl -MKoha::Patrons -MTime::HiRes=time -e '$q={"-or"=>[map{{("me.$_"=>{like=>"%nick%"})}}qw(surname firstname cardnumber)]};$t=time;$rs=Koha::Patrons->search($q,{prefetch=>"branchcode"});$c=$rs->count;$p=time-$t;$t=time;$rs=Koha::Patrons->search($q);$c=$rs->count;$n=time-$t;printf"Pagination COUNT with prefetch: %.4fs\nPagination COUNT without: %.4fs\nSlowdown: %.1fx\n",$p,$n,$p/$n' Pagination COUNT with prefetch: 2.7349s Pagination COUNT without: 0.8491s Slowdown: 3.2x ``` The key here is that 'prefetch' not only introduces a JOIN, but also makes DBIC inflate the DB response into structures, so it takes a lot of resources, adding to the API response latency. This oneliner highlights a specific design issue. I'll now explain how it impacts API searches: When we invoke `objects.search_rs`, we usually do it with pagination parameters and filters (on the UI, for example in patron search). This means the actual search shouldn't have a performance impact because the resultset is tiny! But there's a catch: before adding pagination and filters, we perform a `search->count()` on the resultset! To populate our pagination-related headers (x-total-count, etc)! So we are effectively performing a search, with many joins and hashref inflation on the full resultset, only to get a count! I'll provide a trivial patch for this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20271] New: Merge deleted/old tables with their "alive" cousins
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 Bug ID: 20271 Summary: Merge deleted/old tables with their "alive" cousins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P1 - high Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: boutrosboutrosboutros(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In Koha's DB, instead of having a "soft" deletion of entries by flagging the deleted one as so, the rows in the db is actually deleted, but only after a new row in a different table is inserted. Koha's DB is relational, so there is a cascade of links between each object: a biblio is referred by many items, and each item is referred by issues, holds, messages. E.g.: when a row in the item table is moved from "items" to "deleted_items", then all the references from holds, transfers and so on will be broken. The suggested more orthodox approach to this would be to add a "deleted_at" column, which is normally null unless the row is deleted, then it set to the timestamp of when it was deletion. This means that the row is still there and will still be referred by other tables, but it just won't be shown in the relevant lists. This would improve the maintenance of Koha in many ways (e.g.: the auto_increment id on those tables caused lots of issues when you add an item and delete it immediately after. the next new item will have the same itemnumber as the previously deleted one, clashing with it in many ways). This bug is about merging the all these tables: deletedborrowers => borrowers deletedbiblio => biblio deletedbiblioitems => biblioitems deletedbiblio_metadata => biblio_metadata deleteditems => items old_issues => issues old_reserves => reserves -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 383

[Bug 40868] New: Vendor module permissions are ignored
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40868 Bug ID: 40868 Summary: Vendor module permissions are ignored 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org In the vendors vue app, if a patron doesn't have the full set of permissions (i.e. acquisitions: '*') then all acquisitions permissions are ignored To recreate: 1) Create or edit a user to have all acquisitions permissions except one (not relevant which one, any will do) 2) Log into the staff interface and go to acquisitions > vendors and click the vendor in the table 3) The left menu will be missing everything except invoices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20