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

[Bug 36261] New: Calculating OpacHiddenItems is too slow in OPAC search
by bugzilla-daemon＠bugs.koha-community.org 25 Dec '25

25 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36261 Bug ID: 36261 Summary: Calculating OpacHiddenItems is too slow in OPAC search Change sponsored?: --- Product: Koha Version: master 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Calculating items and records hidden by OpacHiddenItems it slow. Too slow. Fortunately, I've come up with an optimization which seems to effectively eliminate the overhead added by OpacHiddenItems. Basically, instead of running 1 query per item, I run 1 query per bib to get all hidden items. It's pretty straightforward, but I'd like to battle-test it a bit more. I'm also writing this optimization for an older version of Koha, and I still have more optimizing I want to do, so I'm not going to post my patch just yet... It's coming though! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 41051] New: QueryFuzzy syspref description not clear about how it affects Elasticsearch.
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41051 Bug ID: 41051 Summary: QueryFuzzy syspref description not clear about how it affects Elasticsearch. Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex(a)rcls.org QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de An otherwise intelligent sysadmin may wonder why Elasticsearch fuzzy searches with "~" don't work and go looking for answers. The current phrasing of the QueryFuzzy syspref is unclear and suggests that the syspref only affects users of Zebra. This is not the case, as the syspref must be set to "Try" on Elasticsearch systems as well in order to enable fuzzy searches. Current phrasing: [Try/Don't Try] to match similarly spelled words in a search. (For example, a search for flang would also match flange and fang; Currently only affects Zebra searches. Any Elasticsearch term can be made fuzzy by adding a ~ directly after the term.) Suggested wording: [Try/Don't Try] to match similarly spelled words in a search. (For example, a search for flang would also match flange and fang.) If using Zebra, searches become fuzzy by default. If using Elasticsearch, a term must be made fuzzy by adding a ~ directly after the term. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 33228] New: All charges should be displayed on the patron checkout page
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33228 Bug ID: 33228 Summary: All charges should be displayed on the patron checkout page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently charges are only being displayed on the patron checkout page if they are being used as a restriction. If libraries choose to not restrict patrons because of unpaid fines then the only way they can see the fines is by checking the accounting page. It would be ideal if all unpaid fees could be displayed on the checkout page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|victor(a)tuxayo.net | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37673] New: Floating Header Overlap Issue When Switching Tabs in Patron Record
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37673 Bug ID: 37673 Summary: Floating Header Overlap Issue When Switching Tabs in Patron Record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 170469 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170469&action=e… Example of overlapping headers Steps to Reproduce: 1. Prepare the Patron Record: * Ensure you have enough items checked out and on hold to enable scrolling in both tabs. Alternatively, adjust your screen size so that scrolling is necessary. 2. Verify Checkouts Tab: * Go to the "Checkouts" tab. * Scroll through the table to observe that the table header remains consistent and fixed as you scroll. 3. Check Holds Tab: * Switch to the "Holds" tab. * Initially, the table header should appear correct. * Start scrolling and observe that the header changes from the "Holds" floating header to the "Checkouts" floating header. This is noticeable as the first column header changes from "Hold date" to "Due date." 4. Return to Checkouts Tab: * Switch back to the "Checkouts" tab. * Begin scrolling slowly and observe that the "Holds" floating header briefly overlaps with the "Checkouts" floating header. Expected Behavior: * Each tab ("Checkouts" and "Holds") should have its own distinct floating header that remains consistent with the corresponding table content while scrolling. Actual Behavior: * The floating header of the "Holds" tab briefly changes to the "Checkouts" floating header when scrolling, causing overlap between the headers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39593] New: Show branch hours in OPAC
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39593 Bug ID: 39593 Summary: Show branch hours in OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if there were a way to display the library hours defined in libraries on the OPAC library listing. Preferably in the desired format (24hr or 12hr). I am not finding any information about whether this is possible yet. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 --- Comment #449 from Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> --- Created attachment 190712 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=190712&action=e… Bug 41432: Prefetch items and borrowers for holds To test: 1 - Add a bunch of holds to a record https://github.com/kidclamp/handy-koha-script/blob/main/randhold.pl 2 - Enable profiling: https://wiki.koha-community.org/wiki/Profiling_with_Devel::NYTProf#NYTProf_… 3 - Browse to the record and load the holds table 4 - View the flame graph for the request like instructions in #2 5 - Note that Koha::Hold->borrower and Koha::Hold->item take a lot of time 6 - Apply patch, restart all 7 - Reload page 8 - Reload flame graph 9 - Note time for fetching borrowers and items is significantly reduced 10 - Sing off! Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> Signed-off-by: Lucas Gass <lucas(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190711|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

1 0

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '25

24 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 --- Comment #448 from Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> --- Created attachment 190711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=190711&action=e… [#36] Add iterative error handling for invalid QA contacts When a user enters an invalid QA contact email (e.g., a typo or non-existent user), the bug update would fail with a 404 error and the spinner would hang indefinitely. This commit adds comprehensive error handling with user search and iterative retry logic. Changes: - Added search_users() method to RestClient.pm to query Bugzilla's user API endpoint with authentication token - Added select_qa_contact() method to Edit.pm and Attach.pm that: * Extracts the local part of the invalid email (before @) * Searches for similar users whose emails begin with that pattern * Presents a numbered list of matching users for selection * Allows manual entry if no matches found - Implemented iterative retry loop in both Edit and Attach commands: * On 404 error, searches for similar users * User can select from results or enter a different email * If manually entered email also fails, searches again * Continues until successful update or user cancels * Properly stops spinner on each error before continuing Example flow: 1. User enters "martinrenvoize(a)theke.io" → 404 2. Searches for "martinrenvoize" → no results 3. User enters "martin.renvoize(a)theke.io" → 404 4. Searches for "martin.renvoize" → finds matches 5. User selects "martin.renvoize(a)openfifth.co.uk" → success This provides a much better user experience than the previous behavior of hanging indefinitely with no feedback. -- You are receiving this mail because: You are watching all bug changes.

1 0