February 2026 - Koha-bugs - lists.koha-community.org

[Bug 35754] New: Place multiple item-group holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35754 Bug ID: 35754 Summary: Place multiple item-group holds at once for the same record 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: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the availability for item-groups and item group holds it make it very easy for patrons to place a hold on a group of items. This enhancement would provide an option to place multiple item-group holds for the same record. An example use case could be a patron wants to place a hold on volume 4, 5, and 6. Current behavior requires the user to place a hold for vol 4, then place another for vol 5, then finally place a hold for vol 6. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 19060] New: Patrons should not get a max fines block auto-renewal notification for items due in the future.
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19060 Bug ID: 19060 Summary: Patrons should not get a max fines block auto-renewal notification for items due in the future. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org This appears related to 19014. Current functionality in 17.05: Auto-renewal is enabled for specific user and item type combinations. This user has fines in excess of that specified in OPACFineNoRenewalBlockAutoRenewal This user has an item due today, and others due at various times in the future, some many weeks ahead. When the auto-renewal job runs today, Koha is sending an AUTO_RENEWAL email to this user for each of the items on loan, warning that each has failed automatic renewal. Desired functionality in 17.05: When the auto-renewal job runs, Koha should only send an AUTO_RENEWAL failure email to the user for item(s) due for automatic renewal today. Other items are still validly on loan and are not due for renewal. The user is being contacted multiple times unnecessarily and this can be confusing. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41850] New: Allow to choose message type for CheckPrevCheckout
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41850 Bug ID: 41850 Summary: Allow to choose message type for CheckPrevCheckout 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, if the staff member doesn't have the force_checkout permission, the CheckPrevCheckout parameter is enabled, and the patron already checked out the title in the past, the checkout is blocked and the staff member cannot proceed. It would be great if libraries could choose if CheckPrevCheckout is a blocking warning or a simple message. I've had this comment from a library where the librarian doesn't want the circulation staff to be able to override checkouts to patrons with unpaid fines over noissuescharge for example, but still wants them to be able to check out previously checked out items. I was thinking maybe a system preference to choose the type of message (warning = yellow with confirmation button; or message = blue without confirmation). I'm not sure if most libraries use CheckPrevCheckout as a blocking mechanism for checkouts like noissuescharge or age restriction that actually need a confirmation, or rather a more informative message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41849 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13944] Fund sorting is inconsistent across different parts of Koha
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13944 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |41553 CC| |andrew(a)bywatersolutions.com --- Comment #6 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Testing on main today, most things sort the same (though display differs a little). Shipping and adjustments sort differently. I've got three funds, created in the following order: Fund code Z, Fund name A Fund code Y, Fund name B (this is a subfund of Fund Z) Fund code X, Fund name C Fund code W, Fund name D (this is a subfund of Fund z) Acq main page (/acqui/acqui-home.pl): funds sort alphabetically by code, with subfunds alphabetical under their parent. So my funds go: X Z - W - Y Funds in admin (/admin/aqbudgets.pl): funds sort alphabetically by code, with subfunds alphabetical under their parent. So my funds go: X Z - W - Y Funds pulldown for an order line (/acqui/neworderempty.pl): funds sort alphabetically by code, with subfunds alphabetical under their parent. Without bug 41553, these display the fund name but sort by fund code. So, the same sort as the two pages above, but displayed as: C A - D - B Fund pulldown when receiving (acqui/orderreceive.pl): funds sort alphabetically by code, with subfunds alphabetical under their parent. Funds display name while sorting by code. So my funds go: C A - D - B Shipping fund on a new invoice (/acqui/parcels.pl): funds sort alphabetically by name, with no consideration of parent/sub funds. So my funds go: A B C D Fund dropdown for adjustments (acqui/invoice.pl): funds sort alphabetically by name, with no consideration of parent/sub funds. So my funds go: A B C D Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41553 [Bug 41553] Add fund code to the fund dropdown list when adding an item to an order (neworderempty.pl) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41404] New: No need to check related guarantor/guarantee charges when the limits are not set
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41404 Bug ID: 41404 Summary: No need to check related guarantor/guarantee charges when the limits are not set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the code: # Check the debt of this patrons guarantees if ( defined $no_issues_charge_guarantees ) { # Check the debt of this patrons guarantors *and* the guarantees of those guarantors if ( defined $no_issues_charge_guarantors_with_guarantees ) { It is not possible to undef the system preferences, they are set as blank for no value - we need to check if they are numbers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 --- Comment #76 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Looking at the timestamp these patches have been sitting untouched since February 2023 - Koha tends to move on quickly, there might be quite a bit of work required to get this working again and comply with current coding guidelines and best practices. Maybe not the easiest to start out with. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41847] New: Save and preview of routing list reloads subscription detail
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41847 Bug ID: 41847 Summary: Save and preview of routing list reloads subscription detail Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To Replicate: 1. Ensure the RoutingSerials system preference is set to Use. 2. Edit routing list. 3. Add recipients and add a note. 4. Save. 5. Click on save and preview routing slip. A print preview opens for the routing list. The pop-up modal gives the option to print or close the window. In the mean time, the page with the routing list preview reloads and displays the subscription detail. Reloading the page assumes the user has succeeded in editing the routing list and no longer needs to preview the list. If the user decides the routing slip needs further edits, they have to close the window and click on edit routing list again. Instead, the page should not reload to the subscription detail page and should wait for the user to decide what to do next. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 37097] New: koha is not responding due to lack of free disk space (zebra tmp suddenly grows)
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37097 Bug ID: 37097 Summary: koha is not responding due to lack of free disk space (zebra tmp suddenly grows) Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: yuriy.kotsyuk(a)oa.edu.ua Periodically we have a problem with free space on our koha server on Ubuntu 20.04.6. The total disk capacity is 210 GB (koha usually takes 105 GB), but sometimes the number of files in /var/lib/koha/library/biblios/tmp suddenly grows and takes up all the free disk space. As a result, koha server starts working with errors and stops completely. I have come to the conclusion that this folder holds temporary zebra files. I just clear the tmp folder each time. After that, the koha wakes up. Is that an issue with a small disk, or is that an issue with periodical cleaning tmp folder? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 --- Comment #75 from Mykle <mykle.law(a)familysearch.org> --- (In reply to Mykle from comment #74) > I'm curious about this implementation, but I'm new to Koha's code-- as in > brand new. > > How might I get enough of the code to look at that I have context necessary > to experiment with-- I'm looking for food for thought and some code to > analyze or tinker with. > > This seems like it's legitimately complicated, but GIT-style change-tracking > would have inordinate value, I think. For clarity-- I can see the attachments, but I'm wondering about additional context I might need-- there is a mention of adding permissions to MaRC that would make this implementation scale badly-- what additional context might be helpful? -- You are receiving this mail because: You are watching all bug changes.

1 0