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

[Bug 21731] New: t::lib::QA::TemplateFilters missing built-in TT filter "xml" causes false warnings
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21731 Bug ID: 21731 Summary: t::lib::QA::TemplateFilters missing built-in TT filter "xml" causes false warnings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I'm getting the following warning from the QA script: missing_filter at line 15 ( <div style="white-space:pre">[% record | xml %]</div>) I clearly do have an xml filter there. Josef has said it's because it's missing from t::lib::QA::TemplateFilters. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 34021] New: Add option to search within results on the opac interface
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34021 Bug ID: 34021 Summary: Add option to search within results on the opac interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org related: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27546 In 22.11 has been added the option of searching within results of a search, it should be nice to add also to opac. Or even it could be improved with the chance of search within subcollections.. It should be great if a search could be filtered by default via itypetype, ccode or anyother value in item or perhaps and biblio and koha keeps the filter in all searches of a user does. For example: if a library have a special collection of old books, and a user starts a search limiting by collection, let the filter on and being able to search within results now a facet filter od ccode limitation is lost when launch a search BR -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 32203] New: Refactor checkauth() auth rejected to improve maintainability
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32203 Bug ID: 32203 Summary: Refactor checkauth() auth rejected to improve maintainability Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org checkauth() appears to be 706 lines at the time of this writing. The "AUTH rejected" section is 154 lines or over 20% of the function. It's a section devoted mainly to setting up the authentication template, so it's a very low risk part to change, and for the most part easy to change, since you just need to check the display on a failed auth. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 29783] New: Account lockout message appears incorrectly for blank userid
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29783 Bug ID: 29783 Summary: Account lockout message appears incorrectly for blank userid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org If a Koha instance has a borrower with an blank/empty userid and login_attempts over the threshold defined by FailedLoginAttempts, a user will see "Error: This account has been locked!" when visiting the staff interface for the first time and without supplying any login details. This is because we're doing a Koha::Patrons->find with an empty string! The solution is very simple... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 33701] New: Catalogue detail page no longer shows all tab data when printing
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33701 Bug ID: 33701 Summary: Catalogue detail page no longer shows all tab data when printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Before the staff interface styling change, the data for the tabs "Holdings", "Descriptions", "Acquisition details", "Images", etc would be printed out vertically when printing the detail page. Now, when printing the detail page in the staff interface, it just shows the tab headings and the content/data for the active tab. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 32500] New: OPAC_REG_VERIFY has too many options for "Message body"
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32500 Bug ID: 32500 Summary: OPAC_REG_VERIFY has too many options for "Message body" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When creating the "Message body" for the "OPAC_REG_VERIFY" email template, the only available options should be <<OPACBaseURL>> and <<borrower_modifications.verification_token>> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 27267] New: Create more efficient daemon for indexing Zebra
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27267 Bug ID: 27267 Summary: Create more efficient daemon for indexing Zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au At the moment, each instance of Koha on a server gets its own rebuild_zebra.pl daemon which uses approximately 170MB of RAM when idling. While this is not a huge amount on its own, it does not scale well when you start adding many Koha instances on the server. It would be very possible to have 10GB of RAM taken up on a server by idle rebuild_zebra.pl processes alone. In 2018, I wrote a custom Koha indexer daemon (on a non-Debian based OS) which only uses 12MB of RAM. It gets a list of Koha instances, queries the zebraqueue table in those instances, and then forks child processes to run rebuild_zebra.pl (in non-daemon mode) for Koha instances that need it. It also uses advisory file locking, so that only 1 rebuild_zebra.pl process will run per instance at any given time. I would need to refactor the daemon to run using the Debian Koha tooling, but I think that this would be a useful addition to Koha, especially for vendors and other large organisations running multiple Koha instances. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 27301] New: Harmonize methods for providing biblionumbers to opac-reserve.pl
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27301 Bug ID: 27301 Summary: Harmonize methods for providing biblionumbers to opac-reserve.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At the moment, you can send biblionumbers to opac-reserve.pl either as multiple "biblionumbers" arguments or as a single compacted string like "1/2/3". It seems silly to me to have all this code for handling these different scenarios. We should just harmonize the callers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 38981] New: Local cover images failing to load in OPAC search results
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38981 Bug ID: 38981 Summary: Local cover images failing to load in OPAC search results Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org It looks like bug 26933 might've broke OPAC local cover images in the search results due to a possible race condition. In koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-results.tt around line 630 there is a window.load() call which runs 'wait_for_images(verify_cover_images)'. If you're only using OPACLocalCoverImages, there is no wait, so verify_cover_images() is called immediately. That function removes the .cover-image element if there are no images. In the case of OPACLocalCoverImages, there are no images yet, so the element gets removed. Now there are no images yet because 'KOHA.LocalCover.GetCoverFromBibnumber(false);', the function which populates the local cover image elements, hasn't even run yet. Note that it's called within a $(document).ready() which is written lower than the window.load() It's possible that different configurations would yield different results, if they load different resources at different times, which could affect when the handlers run. I've observed the above when using a fairly vanilla koha-testing-docker. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 38072] New: Regression with modalPrint
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38072 Bug ID: 38072 Summary: Regression with modalPrint Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have a few instanced of modalPrint in Koha and they appear to have all ceased to function. returns (bundle modal) and cash registers (cashup summary) are both affected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50