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

[Bug 30096] New: Allow to change "late issue notification" setting in subscriptions batch modification tool
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30096 Bug ID: 30096 Summary: Allow to change "late issue notification" setting in subscriptions batch modification tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29997 Bug 29997 adds a "late issue notification" setting for subscriptions. This bug is for being able to modify this setting in the subscriptions batch modification tool. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29997 [Bug 29997] Allow to send email notification when a serial issue is late -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 42993] New: Koha::Edifact::Transport should log transport failures via Koha::Logger
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42993 Bug ID: 42993 Summary: Koha::Edifact::Transport should log transport failures via Koha::Logger 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Edifact::Transport reports every transport failure (no transport configured, connect failure, directory-change failure, file-listing failure and per-file download/upload failure) with carp. Under misc/cronjobs/edi_cron.pl these go to STDERR, so on a normal cron run the messages are lost: EDI simply goes quiet with nothing in editrace.log to explain why. This routes those failures through Koha::Logger on the 'edi' interface (the same interface edi_cron.pl already uses) so they are recorded in the EDI log. The two ingest()-level data warnings (duplicate filename, unreadable file) are intentionally left as carp: one is asserted by the existing unit test and neither is a transport failure. No change to the transfer logic. Test plan: 1. prove t/db_dependent/Koha/Edifact/Transport.t 2. Point an EDI account at an unreachable transport and run misc/cronjobs/edi_cron.pl; confirm the failure is now written to the EDI log rather than only to STDERR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42987] New: Opac renewal column does not have select all/none links
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42987 Bug ID: 42987 Summary: Opac renewal column does not have select all/none links Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The opac-user.pl page does not give the patron the option to select all/none in the renewal column like the staff have on circulation.pl. Is that purposeful, or should it be added? -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 39769] New: es_indexer_daemon.pl uses stale L1 cache
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39769 Bug ID: 39769 Summary: es_indexer_daemon.pl uses stale L1 cache Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As bug 36549 notes, the es_indexer_daemon.pl doesn't fork child processes to do its work. This leads to memory leaks, but it also means that it's using a stale L1 cache. If you update a system preference like IncludeSeeFromInSearches, you have to restart your es_indexer_daemon.pl worker before you can re-index your database. Note that the solution to this problem does not have to be updating the daemon to fork child process workers. Rather, we need to clear the L1 cache after we fetch a job. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 38407] New: Eliminate event handler attributes in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 Bug ID: 38407 Summary: Eliminate event handler attributes in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Like bug 34709 but for the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 42989] New: AccountAutoReconcile should apply to rental charges and overdue charges
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42989 Bug ID: 42989 Summary: AccountAutoReconcile should apply to rental charges and overdue charges 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: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The AccountAutoReconcile system preference, when set to 'Do', automatically balances a patron's debits and credits after a transaction. However, it does not apply to all transactions; in particular, it does not apply to rental charges and overdue charges. It is not logical for the reconciliation to happen automatically for some transactions and not for others. To replicate on main using KTD or a sandbox: 1. Go to Administration > System preferences. 2. Search for AccountAutoReconcile and set it to 'Do'. 3. Go to a user account, e.g. cardnumber 23529000033739. 4. On this user account, go to Accounting > Create manual credit. 5. Add a credit, e.g. Description = Credit; Amount = 20.00. 6. Still in the user's Accounting view, switch to Create manual invoice. 7. Add a manual invoice, e.g. Type = Lost item; Description = Lost item; Amount = 10.00. Save. 8. Still in the user's Accounting view, switch to Make a payment. Observe that the user has no outstanding charges: the credit and debit amount have been automatically reconciled, leaving the user in credit. 9. Go to Administration > Item types. Check that the Music item type has a rental charge of 5.00. 10. Go to user account's 23529000033739 > Check out view. 11. Note the message "Attention. Credits: Patron has outstanding credits of 10.00". 12. Check out Music item 39999000013634. 13. Note the message is now "Attention. Charges: Patron has outstanding charges of 5.00. Credits: Patron has outstanding credits of 10.00". This is a sign that unlike in steps 7-8, the debit and credit have not been automatically reconciled. 14. On this user account, go to Accounting > Make a payment. 15. Confirm that, unlike in step 8, there are outstanding credits to be applied manually. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42938] New: Allow AccountAutoReconcile to apply for when outstanding charge is lower than credit
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42938 Bug ID: 42938 Summary: Allow AccountAutoReconcile to apply for when outstanding charge is lower than credit Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- We want to be able to allow for AccountAutoReconcile to be enabled for when a outstanding charge is lower than the credit as well as when it is higher. At the moment, AccountAutoReconcile applies if: - when the outstanding charges are higher than the credit - when the outstanding charges equal the credit We want this also to work if the outstanding charge is lower than the credit so that staff don't have to manually apply this credit to them patron account. This is important for us as we are using Bookings for music hire for which there is a paid charge and we are using the loans workflow for this payment charging function. We have a checkout fee that equates to 30 days rental and then the overdue and renewal charges are set up for 30 days with the same amount as the checkout fee. Customers add credit to the account for the total days hire which should then deduce automatically using the renewal and overdues workflow. However, this is not happening currently due to the limitations with when AccountAutoReconcile is applicable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 24782] New: Calendar edit only applies to first day
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24782 Bug ID: 24782 Summary: Calendar edit only applies to first day Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org When editing holidays edit only applies to first day (from date). To test: 1. Add holidays on range e.g from 04/03 to 06/03 2. Try edit these holidays so that from date is 04/03 and to date is set to 06/03 3. Save => Only 04/03 is changed There should be option to edit holidays on range. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42984] New: Filtering by date, expiration date, and details on biblio holds table
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42984 Bug ID: 42984 Summary: Filtering by date, expiration date, and details on biblio holds table Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 23269, 42915 Target Milestone: --- Bug 23269 changed some filtering behavior on the biblio holds table. Bug 42915 restores some of that functionality. Comparing filtering here between 25.05 and main, some differences remain. 25.05 allows one to filter by the values in the Date and Expiration Date columns. This is not possible on main. It's worth noting that this filtering is a little off in 25.05 and seems to be filtering on the un-formatted date value rather than the date as displayed. If a hold is showing a date of "08/02/2026," it will show when filtering to "2026-08-02" but not when filtering to "08/02/2026." Ideally, it would filter based on the display value. 25.05 also allows filtering based on some values in the Details column, while main does not. Though 25.05 also functions imperfectly here. When I have a mix of "Next Available" and "Non priority" holds, I don't get anything when I filter to "next," but I do get my non priority hold when filtering to "non." For item-specific holds, I can filter by the item barcode. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 [Bug 23269] Long hold queues are slowing the service https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42915 [Bug 42915] Filtering Holds table by patron name or pickup library is broken -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42981] New: ERM package result list hangs when filtering by vendor and search status is saved
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '26

03 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42981 Bug ID: 42981 Summary: ERM package result list hangs when filtering by vendor and search status is saved Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Target Milestone: --- Problem: When the search status is saved on a page, the ERM package results list freezes when filtering by vendor. The issue is reproducible with the following steps: 1.) Admin - table settings: cgi-bin/koha/admin/columns_settings.pl#eholdings|packages Activate checkbox "Save search state on page change" 2.) Go to ERM : cgi-bin/koha/erm/eholdings/local/packages And create two packages: - One package with My Vendor assigned. - One package without a vendor. 3.) Filter the package results list by My Vendor. --> List is filtered to one package 4.) Leave the page, for example by navigating to Agreements. Return to the Packages list and you will see the issue (See also attached Screenshot) Actual result: The package results list becomes unresponsive / hangs after returning to the page. Expected result: The package results list should load and display the filtered results correctly. -- You are receiving this mail because: You are watching all bug changes.

1 8