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

[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 41364] New: Error in preservation module breadcrumb
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41364 Bug ID: 41364 Summary: Error in preservation module breadcrumb Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Preservation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com The breadcrumb has an empty element (where 'Processings' should show), and the browser console shows this warning: ``` [Vue Router warn]: No match found for location with path "/cgi-bin/koha/preservation/settings/processings" devtools-BLCumUwL.mjs:59:1 ``` This also fails: ```shell $ ktd --shell k$ run_cypress --spec t/cypress/integration/Preservation/Settings.ts ``` -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[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

[Bug 38872] New: Only first 'a' node tested for wrong filters
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38872 Bug ID: 38872 Summary: Only first 'a' node tested for wrong filters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 21576 If several 'a' elements are on the same line, only the first one will be tested for wrong filters. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21576 [Bug 21576] Add a developer script to automatically fix missing filters -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 39823] New: Sushi harvest can fail with no report
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39823 Bug ID: 39823 Summary: Sushi harvest can fail with no report Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk A library was having issues with Sushi harvests, the test connection passed, however, the harvest failed with no info. Dumping the response on the command line: '_content' => '{"Code": 2010, "Message": "Requestor is Not Authorized to Access Usage for Institution"}' It seems _sushi_errors doesn't handle the case of a code and message but no severity marker This was Gale Cengage -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 40033] New: admin/background_jobs.pl calls GetPlugins incorrectly
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40033 Bug ID: 40033 Summary: admin/background_jobs.pl calls GetPlugins incorrectly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org In the aforementioned script, GetPlugins is used as so: ``` my @plugins = Koha::Plugins::GetPlugins( { method => 'background_tasks', } ); my @plugin_job_types; for my $plugin (@plugins) { my $tasks = $plugin->background_tasks; ``` This currently results in a 500 when it tries to call background_tasks on a plugin that doesn't have it. The reason for this is an incorrect method call to GetPlugins – since there is no invocant, the $params get intepreted as $self (with $params ending up undefined), and so the method filtering doesn't work – which is why we end up calling background_tasks on plugins we did not want to. In the rest of Koha it's universally used as `Koha::Plugins->new()->GetPlugins()`, so it makes sense to follow that trend here. At the same time, I wonder if a more strict linting rules (or a safer API) could've prevented it from happening in the first place. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24