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

[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

[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 38892] New: Patron category 'can be a guarantee' means that same category cannot be a guarantor (bis)
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38892 Bug ID: 38892 Summary: Patron category 'can be a guarantee' means that same category cannot be a guarantor (bis) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think this was not completely fixed in bug 37892. When adding a patron, you cannot choose a guarantor with the same category. To recreate: 1, Go to Patrons 2. Click 'New patron' > 'Kid' 3. Fill out surname and cardnumber 4. Under Patron guarantor, click Add guarantor 5. Search for category = Kid and choose one of the patrons 6. Choose the relationship 7. Click 'Save' --> Error A guarantor cannot be a guarantee. This patron is not a guarantor. This error does not make sense. ***Note that it also blocks editing a patron that has the same category as their guarantor when coming from an upgrade!*** I think this a major, if not critical. I get that the example with 'Kid' does not make much sense, but I just wanted to avoid having to go into patron categories to change the 'Patron' category for example to 'can be guarantee' and make the example with two 'Patron' patrons. Not all libraries classify their patrons with kid/adult. It might be resident/non-resident for example, and a resident parent could have a resident guarantee. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 38411] New: When adding multiple items on receive, mandatory fields are not checked
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38411 Bug ID: 38411 Summary: When adding multiple items on receive, mandatory fields are not checked Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org This was fixed Bug #34109 for the case where only one item is added (function addItem) When adding multiple items, the function addMulti is used and it doesn't check mandatory fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 39268] New: Tab Switching Issue: 'My Lists' and 'Public Lists' Sticky, Displaying Incorrect Lists Until Page Refresh
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39268 Bug ID: 39268 Summary: Tab Switching Issue: 'My Lists' and 'Public Lists' Sticky, Displaying Incorrect Lists Until Page Refresh Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There is an issue with the "Your Lists" and "Public Lists" tabs where the list content doesn't update correctly when switching between them. Initially, the lists display correctly. However, when a user clicks between the tabs (e.g., from 'Public Lists' to 'Private Lists' or vice versa), the list content remains stuck on the first tab's content. For instance, if a user starts on the 'Private Lists' tab and switches to the 'Public Lists' tab, the lists from 'Private Lists' continue to display even though the 'Public Lists' tab is selected. Similarly, if a user switches from 'Public Lists' to 'Private Lists', the 'Public Lists' remain visible. This issue persists until the page is refreshed, at which point the lists reset, but the same behavior occurs again upon switching tabs. This causes confusion, especially for staff who need to view both private and public lists and expect the tab content to reflect the selected tab. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39183] New: If using automatic return claim resolution on checkout, each checkout will overwrite the previous resolution (again)
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39183 Bug ID: 39183 Summary: If using automatic return claim resolution on checkout, each checkout will overwrite the previous resolution (again) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The fix from bug 38246 got deleted when a subsequent bug was rebased. :( Same problem, same fix. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 39244] New: Duplicate and change password buttons missing if no borrowerRelationship defined
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '26

15 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39244 Bug ID: 39244 Summary: Duplicate and change password buttons missing if no borrowerRelationship defined Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If borrowerRelationship is empty the "Duplicate" and "change Password" buttons don't show after the patch from Bug 38429 on both 24.11.x and main -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20