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

[Bug 31916] New: It would be nice to make the paging in datatables and search results consistent
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31916 Bug ID: 31916 Summary: It would be nice to make the paging in datatables and search results consistent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 The paging UI is nice in the catalog search results.. it would be great to clone that styling to the general datatables paging? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 40199] New: Datatables search for eUsage/ERM report results is broken
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40199 Bug ID: 40199 Summary: Datatables search for eUsage/ERM report results is broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, michaela.sieber(a)kit.edu, pedro.amorim(a)openfifth.co.uk When using the search input field on top of a eUsage report result, the search gets stuck in "Processing". This is basically the same error as bug 40198, but for another page of the ERM module. To test: - Activate the ERMModule via the system preference - Add at least one data provider - Add at least one report It doesn't matter if you have no data, the empty results table shows the error as well. - Select the report on the "Saved reports" tab - In the (empty) results table, type anything in the general search field on top - Confirm that the "Processing" appears, but doesn't go away Error from console: Uncaught TypeError: col.data is undefined Confirmed in main and in 24.11. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 34358] New: Generalise library selection filter for datatables
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34358 Bug ID: 34358 Summary: Generalise library selection filter for datatables Change sponsored?: --- Product: Koha Version: master 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 add a custom library select option to the patron search results datatable. We should really generalise this away from the patron-search includes so it could be used on other ajax driven datatables with the header row filters enabled. We should support both 'data-filter="libraries"' at the table heading line definition and 'filter: "libraries"' in the datatable column settings definition level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 38295] New: Standardize "select all" behaviours
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38295 Bug ID: 38295 Summary: Standardize "select all" behaviours Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Sometimes it selects all the visible checkboxes, sometimes all the checkboxes from the tables (even the non-visible ones). What is the expected behaviours? Should we be consistent or does it make sense to have different behaviours depending on the context? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 39290] New: Always use pageLength=-1 when paginate is false
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39290 Bug ID: 39290 Summary: Always use pageLength=-1 when paginate is false Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 39289 On bug 39289 I noticed that we pass more than 20 checkouts to the template but only 20 are displayed because we have DataTable's pageLength:20 and paginate:false. Should we always have pageLength set to -1 when paginate is turned off? koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/acqui/duplicate_orders.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcels.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/acqui/z3950_search.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/auth_subfields_structure.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/branch_transfer_limits.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/localization.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/patron-attr-types.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/smart-rules.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/admin/systempreferences.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/z3950_auth_search.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/z3950_search.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation_batch_checkouts.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/transfers_to_send.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/transferstoreceive.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/circ/view_holdsqueue.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/members/purchase-suggestions.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/members/statistics.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/members/update-child.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/plugins/plugins-home.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/reports/itemslost.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/reports/itemtypes.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/reports/serials_stats.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-collection.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/access_files.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_delete_records.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_delete_records.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_extend_due_dates.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_record_modification.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/batch_record_modification.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/holidays.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/holidays.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/en/modules/tools/overduerules.tt: paginate: false, koha-tmpl/intranet-tmpl/prog/js/marc_subfields_structure.js: paginate: false, Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39289 [Bug 39289] Batch extend due date tools only display the first 20 checkouts -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 40816] New: Upgrade DataTables from 2.1.8 to >2.3.4
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40816 Bug ID: 40816 Summary: Upgrade DataTables from 2.1.8 to >2.3.4 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36640 Blocks: 38259 eg. bug 38259 needs DataTables 2.3+ for lengthLabels Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38259 [Bug 38259] Adjust DT's lengthMenu option -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 118

[Bug 23981] New: Inconsistencies with the different prices
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23981 Bug ID: 23981 Summary: Inconsistencies with the different prices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was investigating bug 18639 and I came across some inconsistencies in the prices, where they are used, the calculations, etc. To reproduce : (Note: my vendor setting is "tax excluded" for both list and invoice price, I tried with different settings and as far as I can tell, the result is the same) 1- Create a new basket 2- Add an order 3- In the financial details, enter the following informations (I know it doesn't make sense IRL, but we are entering different prices just to see what goes where): - Vendor price: 10.99 - Tax rate: 0% - Discount: 0% - Retail price: 12.99 - Replacement cost: 15.99 - Actual cost: 18.99 4- Note that Budgeted cost and Total are based on *vendor* price (10.99) 5- Save your order 6- If you have access to your database, check the info that is entered (if you don't have access to your database, you can do an SQL report with the following query SELECT * from aqorders where basketno = X; Substitute de X for your basket number My db shows the following: listprice: 10.990000 unitprice: 18.990000 rrp: 12.99 replacementprice: 15.990000 rrp_tax_excluded: 12.990000 rrp_tax_included: 12.990000 ecost: 10.99 ecost_tax_excluded: 12.990000 ecost_tax_included: 12.990000 Note that the ecost_tax_excluded and ecost_tax_included are not based on ecost, but on rrp. 7- Go back to acquisitions home page and click on the amount ordered in your budget 8- Find your order and note that the estimated cost per unit is the retail price (12.99), not the vendor price (10.99) and not the budgeted cost as calculated during the order (10.99). 9- Close the basket 10- Receive the order 11- On the receipt summary page (which lists all the items yet to be received), the unit cost is the retail price (12.99) and the replacement cost is correct 12- On the item receiving page, the retail price is correct, the replacement price is correct, the budgeted cost is the retail price not the vendor price (listprice) nor the budgeted cost calculated during the order (ecost), the actual price is correct. 13- In the already received page, the prices are correct 14- In the "Spent column" of the budget, the price taken out of the fund is the actual price, which is correct. Summary: - The vendor price/listprice is not used anywhere else than during the first step of the order - The budgeted cost (ecost) is based on the retail price, the order form needs to reflect that Propositions: - Unless there is a good reason to keep it (like someone wanting to discriminate between how much the vendor sells it vs how much another vendor might sell it), I would remove the vendor price completely and replace it with the retail price - Correct the order form to show the real estimated price, based on the retail price - Correct the db calculations to make sure the ecost is based on the rrp and that the tax are calculated on the ecost I'm sorry if this is all over the place, hopefully by following the steps, you will see what I mean. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 38145] New: Having ES enabled but unreachable breaks cataloguing
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38145 Bug ID: 38145 Summary: Having ES enabled but unreachable breaks cataloguing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It seems that changing between Zebra and Elasticsearch produces a bad behavior on the latter, when the search engine is not available. I noticed this while doing some acquisitions where AutoLinkBiblios was set and Koha exploded while trying to link authorities. While writing the steps to reproduce I thought about just adding a record, and boom :-D To reproduce: 1. Start KTD with ES $ ktd --es7 up -d 2. Edit koha-conf.xml so it doesn't find the ES server $ ktd --shell k$ vim /etc/koha/sites/kohadev/koha-conf.xml ... <elasticsearch> <server>potato:9200</server> 3. Catalog a new bibliographic record 4. Click 'Save' => FAIL: Koha explodes: Unable to perform your search. Please try again. at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch/Search.pm line 104 5. Switch SearchEngine=Zebra 6. Stop Zebra: k$ sudo koha-zebra --stop kohadev 7. Repeat 3-4 (you can go back in the browser) => SUCCESS: It saved the record -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 41076] New: Perltidy config needs to be refined to not cause changes with perltidy 20250105
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41076 Bug ID: 41076 Summary: Perltidy config needs to be refined to not cause changes with perltidy 20250105 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: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org 1. KOHA_IMAGE=main-bookworm ktd up 2. prove xt/perltidy.t 3. leave running for like a minute, it passes, don't bother with full run 4. KOHA_IMAGE=main-trixie ktd up 5. prove xt/perltidy.t 6. failures quickly pile up D12: perltidy --version This is perltidy, v20230309 dpkg -l | grep tidy 20230309-1~koha3 (ours) D13: perltidy --version This is perltidy, v20250105 dpkg -l | grep tidy 20250105-1 So in KTD, the D13 image doesn't ship our perltidy so it uses Debian's which is more recent. And might use some different default that aren't covered by our current config. I guess it would be better to complete the config so that both version of perltidy output the same code, right? Rather than making the D13 image ship an old version of perltidy which would postpone the root issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 38426] New: Node.js v18 EOL around 25.05 release time
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38426 Bug ID: 38426 Summary: Node.js v18 EOL around 25.05 release time Change sponsored?: --- 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We need to plan to migrate our used Node.js version to the latest LTS available. EOL dates: https://endoflife.date/nodejs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56