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

[Bug 42322] New: Collapse sidebar
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42322 Bug ID: 42322 Summary: Collapse sidebar Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On bug 42190 we discuss the possibility to collapse the sidebar in order to enlarge the screen and specifically the table in the main div. It would be good to have the behaviour available everywhere, not only on the report result view. -- You are receiving this mail because: You are watching all bug changes.

1 184

[Bug 32776] New: Choose to convert oldest reserve or all possible reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32776 Bug ID: 32776 Summary: Choose to convert oldest reserve or all possible reserves to recalls Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 31415 introduces a script to convert reserves to recalls. By default, it will take the oldest reserve on a record and convert it to a recall. We should be able to customise which reserve(s) are converted to recalls. Options may include: - oldest reserve - one reserve for each issued item available to be recalled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42669] New: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42669 Bug ID: 42669 Summary: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 39769 es_indexer_daemon.pl has two issues that cause silent data loss: 1. When update_index() throws an exception (e.g. NoNodes, BadResponse), the exception is caught and logged, but the job is still marked status='finished'. This means records are never re-indexed and silently disappear from search results. 2. The Search::Elasticsearch client (cxn_pool=Static) marks nodes as 'dead' after a connection failure and applies exponential backoff up to 60 minutes. Since the indexer objects are created once at daemon startup, a brief ES restart (e.g. Docker upgrade) leaves the daemon permanently stuck in NoNodes state until manually restarted. Fix: - On NoNodes: abort the batch, recreate the indexer object (resetting the connection pool), and reset jobs to status='new' for automatic retry. - On other indexing errors: mark jobs as 'failed' instead of 'finished'. Test plan: 1. Start es_indexer_daemon.pl 2. Stop Elasticsearch 3. Add/modify a biblio record (triggers indexing job) 4. Verify the job stays in status='new' (not 'finished') 5. Restart Elasticsearch 6. Verify the job is picked up and indexed successfully Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39769 [Bug 39769] es_indexer_daemon.pl uses stale L1 cache -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 42617] New: ILL availability pagination not working
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42617 Bug ID: 42617 Summary: ILL availability pagination not working Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42568] New: Match maxlength attributes to marc_order_accounts column sizes
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42568 Bug ID: 42568 Summary: Match maxlength attributes to marc_order_accounts column sizes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 34355 There are a few fields in the MARC order accounts entry form which should have a maxlength attribute to prevent an error if the user enters more characters than the db can accept. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34355 [Bug 34355] Automated MARC record ordering process -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 42512] New: Marc control field length detection prevents editing of records with invalid MARCXML
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42512 Bug ID: 42512 Summary: Marc control field length detection prevents editing of records with invalid MARCXML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 34014 made it possible to edit a broken record by stripping non-xml characters from the metadata Bug 40272 added a check for length of control fields, however, it also regenerated the marc record, and didn't catch errors from bad xml We should pass the already cleaned record to the check rather than fetching it again -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 42225] New: On sites with many vendors spent.pl cannot load
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42225 Bug ID: 42225 Summary: On sites with many vendors spent.pl cannot load Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When attempting to click on the spent amount we found that a site with many vendors (~260k) there is a MySQL error: ERROR 1038 (HY001): Out of sort memory, consider increasing server sort buffer size spent.pl uses a large query: 57 my $query = <<EOQ; 58 SELECT 59 aqorders.biblionumber, aqorders.basketno, aqorders.ordernumber, 60 quantity-quantityreceived AS tleft, 61 budgetdate, entrydate, 62 aqbasket.booksellerid, 63 GROUP_CONCAT(DISTINCT itype SEPARATOR '|') as itypes, 64 title, 65 aqorders.invoiceid, 66 aqinvoices.invoicenumber, 67 quantityreceived, 68 $unitprice_field, 69 datereceived, 70 aqbooksellers.name as vendorname 71 FROM (aqorders, aqbasket) 72 LEFT JOIN biblio ON 73 biblio.biblionumber=aqorders.biblionumber 74 LEFT JOIN aqorders_items ON 75 aqorders.ordernumber = aqorders_items.ordernumber 76 LEFT JOIN items ON 77 aqorders_items.itemnumber = items.itemnumber 78 LEFT JOIN aqinvoices ON 79 aqorders.invoiceid = aqinvoices.invoiceid 80 LEFT JOIN aqbooksellers ON 81 aqbasket.booksellerid = aqbooksellers.id 82 WHERE 83 aqorders.basketno=aqbasket.basketno AND 84 budget_id=? AND 85 datecancellationprinted IS NULL AND 86 datereceived IS NOT NULL 87 GROUP BY aqorders.biblionumber, aqorders.basketno, aqorders.ordernumber, 88 tleft, 89 budgetdate, entrydate, 90 aqbasket.booksellerid, 91 title, 92 aqorders.invoiceid, 93 aqinvoices.invoicenumber, 94 quantityreceived, 95 $unitprice_field, 96 datereceived, 97 aqbooksellers.name 98 99 EOQ It seems to work if I join the booksellers after the grouping: SELECT biblionumber, basketno, ordernumber, tleft, budgetdate, entrydate, booksellerid, itypes, title, invoiceid, invoicenumber, quantityreceived, unitprice_tax_included, datereceived, aqbooksellers.name as vendorname FROM (SELECT aqorders.biblionumber, aqorders.basketno, aqorders.ordernumber, quantity-quantityreceived AS tleft, budgetdate, entrydate, aqbasket.booksellerid, GROUP_CONCAT(DISTINCT itype SEPARATOR '|') as itypes, title, aqorders.invoiceid, aqinvoices.invoicenumber, quantityreceived, unitprice_tax_included, datereceived FROM (aqorders, aqbasket) LEFT JOIN biblio ON biblio.biblionumber=aqorders.biblionumber LEFT JOIN aqorders_items ON aqorders.ordernumber = aqorders_items.ordernumber LEFT JOIN items ON aqorders_items.itemnumber = items.itemnumber LEFT JOIN aqinvoices ON aqorders.invoiceid = aqinvoices.invoiceid WHERE aqorders.basketno=aqbasket.basketno AND budget_id=44 AND datecancellationprinted IS NULL AND datereceived IS NOT NULL GROUP BY aqorders.biblionumber, aqorders.basketno, aqorders.ordernumber, tleft, budgetdate, entrydate, aqbasket.booksellerid, title, aqorders.invoiceid, aqinvoices.invoicenumber, quantityreceived, unitprice_tax_included, datereceived ) orders LEFT JOIN aqbooksellers ON orders.booksellerid = aqbooksellers.id -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41819] New: Refunds via the Cash registers page should not result in PAYOUTS if the transaction type is 'Account Credit'
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Bug ID: 41819 Summary: Refunds via the Cash registers page should not result in PAYOUTS if the transaction type is 'Account Credit' Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk We handle account credit correctly from the borrower account page, but if a refund is processed via the cash register page, an account credit is currently generating a PAYOUT line incorrectly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 42430] New: Fix issue with stale plugin methods after plugin upgrade
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42430 Bug ID: 42430 Summary: Fix issue with stale plugin methods after plugin upgrade Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a plugin is upgraded in place (that is, uploading a new version over the old one), the list of methods Koha knows about for that plugin can get out of date. For example, if a plugin used to have a "tool" method and the new version renames it to "admin", the staff interface can still show the old "Run tool" link, and clicking it produces an error saying the plugin has no "tool" method. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 42339] New: Canceling a Record display customization directs to the HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42339 Bug ID: 42339 Summary: Canceling a Record display customization directs to the HTML customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: dmeininger591(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 39860 introduced Record Display Customizations to the Tools module > Additional Content. When editing an entry and then selecting cancel you are returned to the HTML customizations section instead of back to the Record Display Customization. This is not how the other Additional Content tools work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15