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

[Bug 43510] New: EDI invoicing miscalculates tax_value_on_receiving for mixed-rate order lines
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43510 Bug ID: 43510 Summary: EDI invoicing miscalculates tax_value_on_receiving for mixed-rate order lines 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When Koha imports an EDIFACT INVOIC message, it computes tax_value_on_receiving as: quantity * price_excl_tax * tax_rate_on_receiving using only the rate parsed from the *first* TAX segment on the LIN (Koha::Edifact::Line::tax_rate returns on the first match). It never reads the vendor's actual invoiced tax amount, which EDIFACT carries in one or more MOA+124 segments per LIN. This is wrong whenever a vendor invoice line is genuinely mixed-rate - part of the line's value standard-rated, part zero-rated (for example a book bundled with a non-book component). EDIFACT represents this as more than one TAX/MOA segment pair on the same LIN, one pair per rate. Koha only reads the first pair's rate and applies it to the entire line value, hugely overstating the tax on the zero-rated portion. Concrete real-world example (production data, order numbers changed): LIN block for a mixed-rate item, quantity 6, price_excl_tax total 56.46: TAX+7+VAT+++:::20+S MOA+124:2.95 (20% portion, taxable base 14.74) TAX+7+VAT+++:::0+Z MOA+124:0 (0% portion, taxable base 38.00) Vendor's actual invoiced tax for this line: 2.95. Koha's computed tax_value_on_receiving: 6 * (56.46/6) * 0.20 = 11.29. Koha::Edifact::Line already parses the taxable amount and rate per TAX segment (tax_rate, moa_amt('124')), and even has a helper that sums every MOA+124 occurrence on a line (amt_taxoncharge), but nothing in Koha::EDI's invoice receipt code uses it - the flat rate x price recompute in the tax_value_on_receiving assignments is unconditional. We looked at fixing this directly in Koha::EDI but believe it needs the wider acquisitions costing rework rather than a point patch here: aqorders.tax_rate_on_receiving is a single scalar column that cannot represent a split rate, and C4::Acquisition::ModReceiveOrder recomputes tax_value_on_receiving from that single rate on every subsequent receive/edit of the order line. So a fix confined to the EDI ingest path alone would be silently reverted the next time the line is touched through the normal receiving UI. Filing this for visibility so it can be considered as part of that larger effort. Impact: any library receiving EDI invoices from vendors who send genuinely mixed-rate order lines will have Koha significantly overstate the tax recorded against those lines, which then propagates into any local financial reporting or exports built on tax_value_on_receiving. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39781] New: Cannot limit by library when creating custom patron email sent via patron details page
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39781 Bug ID: 39781 Summary: Cannot limit by library when creating custom patron email sent via patron details page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29393 To recreate: 1 - create a new notice in module "Patrons (custom message)" 2 - limit your notice to a library 3 - give your notice content for the email format 4 - go to a patron record, select Add Message 5 - confirm the notice you created appears as an option regardless of whether or not you're logged in at the branch you selected in step 2 6 - confirm the Save button fails to enqueue your notice, regardless of logged-in branch We don't pass any branchcode along with the borrowernumber and letter_code when enqueueing this, so it fails if the notice template is limited to a branch. We should send the logged-in library when enqueueing the notice. We should also high the notice from the Add Message form if the user is not logged in at the correct branch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 42083] New: Email and SMS messages from patron record should have distinct permissions
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42083 Bug ID: 42083 Summary: Email and SMS messages from patron record should have distinct permissions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 40933, 29393 Bug 29393 added the ability to send email from a patron's record. 40933 expanded that to SMS. But they currently share a single permission. It would be preferable for those to be two distinct permissions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40933 [Bug 40933] Add SMS support under Add message feature -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 9725] Add support to notices for hourly loans
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9725 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew(a)bywatersolutions.com Depends on| |10190 --- Comment #2 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- With Bug 10190 pushed to main, overdue triggers can now be set per itemtype, which is a big step toward making this work. We still need: - the ability to define overdue notice delays in hours (currently they're always in days) - a way to run overdue_notices.pl throughout the day without generating repeat notices Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 [Bug 10190] Overdue notice triggers based on item type -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9725 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9725 [Bug 9725] Add support to notices for hourly loans -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39207] New: Improve usability of search when holding a specific item
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39207 Bug ID: 39207 Summary: Improve usability of search when holding a specific item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lauri.hanninen(a)lahti.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 178779 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178779&action=e… Image showing how user's set library blocks filtering due to allowed pickup locations When filtering for a specific item on holds page using the search bar, it's currently not feasible to filter by user's set library. When entering the user's set library in the search field, search results won't narrow down because they include the active selection in the Allowed pickup locations column which by default is the user's set Library. Filtering by user's own library would be one of the common usages for the search field when placing a hold on a specific item, so it would have more usability if it could be fixed. See attached image as an example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43473] New: Removal of lost status via checkout isn't reflected in logs
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43473 Bug ID: 43473 Summary: Removal of lost status via checkout isn't reflected in logs Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If an item with a lost status is checked out without first being checked in, the checkout removes the lost status. However, the removal of the lost status isn't reflected in action logs, which is problematic for troubleshooting. To recreate: -Find an available item and mark it with a lost status (ex: Missing) -Note the bib's Modification log includes the new lost status in the Diff column -Check the item out to a patron (*without* first checking it in) -Note that the Missing status has been cleared from the holdings table (correct) -Note that the bib's Modification log *doesn't* have an entry showing the removal of the lost status (incorrect) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 43491] New: REST API XML payload conversion breaks plugin API routes that read XML
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43491 Bug ID: 43491 Summary: REST API XML payload conversion breaks plugin API routes that read XML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Bug 37762 makes the REST API convert request bodies sent with an application/xml content type to JSON so they can be validated against Koha's swagger definitions, and convert response bodies with an application/xml content type from JSON to XML. Both hooks apply to every route, including the /contrib plugin routes. Plugins define their own API and may consume and produce XML directly. I've been working on a plugin based version of the NCIP server for Koha, with NCIP being entirely XML based. On Koha 26.05 and later the request hook replaces the incoming NCIP message with a JSON rendering of it before the plugin controller runs. The conversion drops element attributes and ordering, so the original message can't be rebuilt from it. In my case it's the attributes that are needed. I have found a workaround by grabbing the raw body from the buffered PSGI input Mojolicious's $c variable. In the other direction, the response hook dies trying to parse the plugin's XML response as JSON, turning it into a 500. This affects Koha 26.05+ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43460] New: REST API XML payload conversion breaks plugin API routes that consume XML
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43460 Bug ID: 43460 Summary: REST API XML payload conversion breaks plugin API routes that consume XML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Bug 37762 makes the REST API convert request bodies sent with an application/xml content type to JSON so they can be validated against Koha's swagger definitions, and convert response bodies with an application/xml content type from JSON to XML. Both hooks apply to every route, including the /contrib plugin routes. Plugins define their own API contracts and may read and output XML directly. For example, the POC for the NCIP server plugin accepts XML messages on its route. On Koha 26.05 and later the request hook replaces the incoming NCIP message with a JSON rendering of it before the plugin controller runs, destroying the message such that element attributes and ordering are lost with no way to get to that data. The response hook then dies trying to parse the plugin's XML response as JSON, turning it into a 500. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 41318] New: AmazonLocale system preference - add Brazil as an option
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41318 Bug ID: 41318 Summary: AmazonLocale system preference - add Brazil as an option Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org See the post on Mattermost chat https://chat.koha-community.org/koha-community/pl/7mr33cigziruzpjsutpy97acka on 27 November 2025: amandap Hello Kohers <3, I would like to propose an enhancement to the AmazonLocale System Preference to include Brazil (amazon.com.br) as a selectable option. Currently, the system preference does not list a Brazilian locale. Brazilian libraries using Koha are forced to select the US (amazon.com) or another locale, which results in a low cover image match rate for Brazilian Portuguese editions, as our editions often differ significantly from those listed in other Amazon stores. Including amazon.com.br would significantly improve the accuracy of cover images displayed on the OPAC and Staff Interface for libraries operating in Brazil and potentially other Portuguese-speaking countries, enhancing the value of the Enhanced Content feature for this region. Thank you for considering this enhancement. -- You are receiving this mail because: You are watching all bug changes.

1 21