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

[Bug 41899] New: Add branchcode in accountlines.branchcode for RESERVE_EXPIRED
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41899 Bug ID: 41899 Summary: Add branchcode in accountlines.branchcode for RESERVE_EXPIRED Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org We need to record the branchcode to the accountlines when the RESERVE_EXPIRED fee is added by the cancel_expired_holds.pl cron job. I think the suitable branchcode could be the hold's pickup library (reserves.branchcode). This change would help to track to which library the fee belongs to (in library consortiums). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 2646] Add sort option for the series number
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2646 --- Comment #13 from Sarah Cornell <sbcornell(a)cityofportsmouth.com> --- We have a nasty assortment of series data as well, but perhaps that helps find all the edge cases! Currently Koha displays series statements in the 490 or 8XX based on the 490 ind1 data. (as of the last time we checked!) It would be good for Koha to use the same or at least consistent logic (.e.g. if 490$v exists, use 490$v, if 490$v does not exist, use 8XX$v) to sort based on series. Also, could a system preference tell Koha which series field to sort by? If a library wants to prefer 8XX$v regardless of the presence of 490$v, then they cantell their system exactly what field to consult when using a "sort by series number" option. Just some ideas. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2646] Add sort option for the series number
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2646 --- Comment #12 from Esther Melander <esther.melander(a)bywatersolutions.com> --- How would Koha handle a series sort when there is more than one series statement with different volume numbers? I am thinking of the Magic Tree House series which was originally published with one series order and then the publisher re-did the series with a new order. That would mean a title could conceivably have two series statements and be sorted in two different ways. This may be an edge example, but I'm sure there are others. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 2646] Add sort option for the series number
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2646 --- Comment #11 from Jason Robb <jrobb(a)sekls.org> --- We have a nice nasty mix of series data in 440s, 490s and 8XXs so we'd want to be able to consider all the possible series fields when doing the sort. Our series titles aren't at all consistent either. I wonder if this would be simplified by only sorting when the search is limited to a specific series title search? -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 2646] Add sort option for the series number
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2646 Jason Robb <jrobb(a)sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb(a)sekls.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

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

1 0

[Bug 41888] New: Cronjob cleanup_database.pl doesn't delete old jobs either by age or type
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41888 Bug ID: 41888 Summary: Cronjob cleanup_database.pl doesn't delete old jobs either by age or type Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The command perl /usr/share/koha/bin/cronjobs/cleanup_database.pl --confirm --jobs-days 7 --jobs-type all <instance> and several variations (e.g. only jobs-days or jobs-type parameter) does not purge any old jobs. What may be the reason? The solution in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30914 was to fix 'delete if $verbose' and set 'delete if $confirm' instead, but I couldn't find the same mistake here. The cleanup seems to fail also when the job runs as a cronjob in koha-common. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35908] New: There is no length limit for what's presented in datatables
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35908 Bug ID: 35908 Summary: There is no length limit for what's presented in datatables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 34574 To reproduce: 1) Create a new patron category, visit: /cgi-bin/koha/admin/categories.pl?op=add_form 2) Add a category code, en enrollment period, a category type and a really long description like: "This is a real long description of the patron category code for demo purposes This is a real long description of the patron category code for demo purposes"" 3) Now do the same but for a library, visit: /cgi-bin/koha/admin/branches.pl?op=add_form 4) Add a library code and a really long name like: "This is a real long library name for demo purposes This is a real long library name for demo purposes" 5) Visit patrons home: /cgi-bin/koha/members/members-home.pl 6) Hit "Search". Notice the "library" and "category" columns grow in width to match the largest option (added in previous steps) 7) Edit a patron, assign that patron the library and category above, go back to the table. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34574 [Bug 34574] Datatables dropdown filter column header is potentially too wide -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41877] New: Accessibility : Holding table under the record can be too wide if filters are activated
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41877 Bug ID: 41877 Summary: Accessibility : Holding table under the record can be too wide if filters are activated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Holding table under the record can be too wide if filters are activated : item type, holding library, home library and status are now filtered by dropdown lists. If the labels of some libraries, types or status are long, their respective columns are enlarged. As a result, the holding table overflows the page, and the action button at the right (Edit) is not visible unless the librarian scrolls the entire page to the right. I have no idea of the best way to fix that, but this is an UX and accessibility issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 9750] Bring routing lists into notices & slips
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '26

19 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9750 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41846 -- You are receiving this mail because: You are watching all bug changes.

1 0