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

[Bug 43382] New: Item, that is attached to item bundle, does not accumulate checkout stats
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43382 Bug ID: 43382 Summary: Item, that is attached to item bundle, does not accumulate checkout stats 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: anni.maki-mantila(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Currently, an item that is attached to an item bundle does not accumulate its own checkout stats when the item bundle is checked out to a patron. Checkout stats are only recorded for the item bundle itself, not for the individual items attached to it. However, an item attached to an item bundle is in fact being loaned to a patron when the bundle is checked out. Therefore, the attached item should also accumulate checkout stats. Checkout stats are used as the basis when paying compansations to authors. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41809] New: Waiting holds fulfilled by another copy should be marked for return to stacks
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Bug ID: 41809 Summary: Waiting holds fulfilled by another copy should be marked for return to stacks Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This may be related to bug 38650 The use case we have run into is: A patron has a hold waiting on the hold shelf. They check out a different copy on the same bib from the stacks and this copy fulfills the hold. The waiting hold does not appear on the holds with cancellations or holds waiting over X days reports. This causes confusion for our branch staff and items sitting on the hold shelf longer than they should be. Ideally these would move to the holds with cancellation requests report, but I'd be interested if others feel differently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 43824] New: Report Run Type should be copied when duplicating a report
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43824 Bug ID: 43824 Summary: Report Run Type should be copied when duplicating a report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42108 Target Milestone: --- Bug 42108 adds the ability to specify whether a report should run in the foreground or the background. This value is not retained when duplicating a report. I think it should be. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 [Bug 42108] Add ability to specify that a report can only be run as a foreground or background report -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43823] New: Show report Run Type in more places
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43823 Bug ID: 43823 Summary: Show report Run Type in more places Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42108 Target Milestone: --- With Bug 42108, one can set a given report to always run in the foreground or always run in the background. Currently, that setting is only visible when editing the report. We should expose it more places: - Show Run type when viewing a report (/cgi-bin/koha/reports/guided_reports.pl?id=NNN&op=show) - Show run type as a configurable column in the saved reports list (/cgi-bin/koha/reports/guided_reports.pl?op=list) In both of these cases, this value/column should only be displated if the ReportsRunInBackground syspref is set to "Let the user choose" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 [Bug 42108] Add ability to specify that a report can only be run as a foreground or background report -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43800] New: Typo in delete_items.pl verbose mode: "cannot deleted"
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43800 Bug ID: 43800 Summary: Typo in delete_items.pl verbose mode: "cannot deleted" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities 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: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- When you try to delete items that are either checked out or on hold using the delete_items.pl script with verbose the printout reads "cannot deleted" instead of "cannot delete". To recreate: 1. Check out an item to a patron (e.g. check out 39999000006018 to Henry Acevedo) -- note the barcode 2. In the terminal, run delete_items.pl for this specific item using the verbose flag ./misc/cronjobs/delete_items.pl --where "barcode = '39999000006018'" --verbose The printout returns [...] cannot deleted: book_on_loan It should be "cannot delete". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43728] New: runreports.pl cronjob should be able to apply reports templates
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43728 Bug ID: 43728 Summary: runreports.pl cronjob should be able to apply reports templates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 34136 Target Milestone: --- When running a report via the runreport cronjob it would be nice to be able to deliver the results as a pdf or HTML document formatted using the template functionality added in Bug 34136. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34136 [Bug 34136] Add ability to render a report using a notice template -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 40892] New: ILL tab with no requests shows all instead
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40892 Bug ID: 40892 Summary: ILL tab with no requests shows all instead Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com With the ILLRequestsTabs feature, if you create a tab for a status which has no matching ILL requests, that tab displays _all_ requests instead of none. We have a tab "new" tab (see below) that exhibits this behavior whenever there are no status=NEW requests. Here's a rough way to recreate this on a new system: - Enable ILLModule setting - Create a few ILL requests - Edit ILLRequestsTabs setting to have two tabs ``` - name: New status: - NEW - name: Completed status: - COMP ``` - Go to the requests module on the staff side - Select the "Completed" tab - There should be 0 requests; instead you see all of them -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 30200] New: Add customizable tabs to interlibrary loan requests list
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30200 Bug ID: 30200 Summary: Add customizable tabs to interlibrary loan requests list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi In staff client, all interlibrary loan requests are loaded into a table regardless of their status. Ability to sort them by status under multiple tabs would make librarians life a lot easier. This Bug adds such feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81

[Bug 43822] New: EDI invoice receipt reassigns already-received order lines when RFF+LI points at a complete order
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43822 Bug ID: 43822 Summary: EDI invoice receipt reassigns already-received order lines when RFF+LI points at a complete order Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions 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::EDI::process_invoice matches each invoice line to an order using the RFF+LI ordernumber only. It never compares the line's EAN/ISBN with the order's biblio. If the RFF+LI ordernumber belongs to an order that is already 'complete' and already attached to a different invoice, Koha adds an edifact_errors warning ("already marked as complete ... The ordernumber in this invoice may be incorrect") and then carries on regardless. The simple-receipt branch overwrites these columns on the existing aqorders row: - invoiceid - datereceived - quantityreceived - unitprice, unitprice_tax_excluded, unitprice_tax_included - tax_rate_on_receiving, tax_value_on_receiving Effects: - The original invoice, which may already be closed and paid, silently loses lines. Its Koha total no longer matches what the supplier billed. - The new invoice holds lines for goods it does not cover, at the new message's prices. - The line's real receipt history is lost. The edifact_errors warning is the only trace. Real-world trigger: a supplier sent a first INVOIC with the correct EANs but stale RFF+LI values pointing at 39 lines of an older, already received and invoiced basket, plus different prices. It then sent a corrected INVOIC with the same invoice number. Koha moved the 39 old lines onto the first invoice, which was then closed and paid. The older closed invoice was left 39 lines short. The supplier data was wrong, but Koha turned a bad message into silent corruption of already-received, already-invoiced lines. EdifactInvoiceImportBlockDuplicates does not help here. It blocks on invoice number, so it would block the supplier's corrected resend rather than the bad message. Test plan (to reproduce): 1. Create a vendor with an EDI account. Order line A (EAN X) and line B (EAN Y) on two baskets. 2. Import INVOIC 1 receiving A (RFF+LI:<A ordernumber>, EAN X). Close that invoice. 3. Import INVOIC 2 (different invoice number) containing EAN Y and different prices, but with RFF+LI:<A ordernumber>. 4. Look at aqorders for A: invoiceid is now INVOIC 2's invoice, and datereceived and unit prices are INVOIC 2's. INVOIC 1's invoice has lost the line. B is still not received. 5. The only trace is an edifact_errors warning on INVOIC 2's message. Expected: a line that is already complete and attached to another invoice is not overwritten. It is skipped and an error is recorded in edifact_errors. Suggested fix: - In process_invoice, when orderstatus is 'complete' and invoiceid is set and differs from the invoice being created, skip the line and record an error instead of only warning. - Optionally cross-check the invoice line's EAN/ISBN against the order's biblio and skip/warn on mismatch. Related: Bug 43756 (EDI invoice processing receives lines for cancelled orders and re-opens them), Bug 43755, Bug 43754. The "already marked as complete" warning was added under Bug 41996. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43501] New: introduce Koha::Item->mark_lost
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43501 Bug ID: 43501 Summary: introduce Koha::Item->mark_lost 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: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To be used by 39756 (long overdue cron control migration to the UI, and therefore to circulation triggers), Koha::Item->mark_lost is modelled on part of LostItem. As 39756 will introduce the ability for administrators to control what status changes occur, in which order, and when by setting delays and separating different actions across different triggers, 39756 cannot rely on LostItem, and requires smaller methods with smaller responsibility scopes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4