Sunday, August 23, 2026
6 changes · saas-19.1
Resolved issues and error corrections
The online shop now blocks confirmation when a signed-in customer reaches payment validation with an empty cart. This prevents accidental creation of confirmed sales orders with no products, keeping order records cleaner and reducing follow-up corrections.
Original PR description
Calling `/shop/payment/validate` as a portal user with an empty cart confirms the empty sale order. Steps to reproduce: - Sign in as a portal user. - Add a product to the cart. - Remove the product. - Go to `/shop/payment/validate`. - The empty sale order is confirmed. opw-6430637 Forward-Port-Of: odoo/odoo#282741 Forward-Port-Of: odoo/odoo#280924
Refunded point-of-sale down payments on sale orders are now handled correctly when creating final invoices or settling the order. This prevents refunded down payments from being counted again, avoiding overstated invoices and incorrect invoiced amounts.
Original PR description
The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69…
The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69 However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order. Steps to reproduce: - Create a sale order. - Pay a down payment through the POS. - Refund the down payment order from the POS. - Settle the remaining amount from the POS or invoice the sale order from the backend. Result: - The generated invoice includes the sale order total plus the refunded down payment. - Sale order `amount_invoiced` will be the down payment amount. Fix: - Delete the refunded downpayment to match the sale flow. - Include refunded down payments in the amount_invoiced computation. opw-6378891 Forward-Port-Of: odoo/odoo#283308 Forward-Port-Of: odoo/odoo#278011
Mentioning a partner linked to multiple active users no longer causes an error in sub-channel discussions. Odoo now checks each user's notification preference and invites the partner when at least one linked user allows channel notifications, keeping conversations from being interrupted.
Original PR description
Before this commit, mentioning a partner that has two active users in a sub-channel ended on: ValueError: Expected singleton: res.users.settings(77, 80) This happens because the channel notification setting is read through res_users_settings_id, a Many2one on res.users, so two users give two settings records and reading a value on them asks for a singleton. Only an administrator reaches it, as the res.users.settings rule limits everyone else to their own settings. This commit fixes the issue by inviting the partner as soon as one of its users did not turn channel notifications off. Forward-Port-Of: odoo/odoo#283912 Forward-Port-Of: odoo/odoo#283805
This update refreshes Odoo's spreadsheet component with fixes that improve how filters sort data with headers and how numbers display using the user's local decimal separator. It also includes minor visual and maintenance updates, helping spreadsheets behave more consistently for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d34d0e73d9 [REL] 19.1.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d34d0e73d9 [REL] 19.1.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b34d534e9d [FIX] inputs: explicitly define border-style [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4396cc1cbe [FIX] filter_menu: take number of headers into account when sorting [Task: 6471792](https://www.odoo.com/odoo/2328/tasks/6471792) https://github.com/odoo/o-spreadsheet/commit/ea70823de1 [IMP] claude: add gitignore for claude local settings [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cb6ac6156b [FIX] toLocaleString : new helper to use the locale's decimal separator [Task: 6232818](https://www.odoo.com/odoo/2328/tasks/6232818) https://github.com/odoo/o-spreadsheet/commit/0792c4f799 [FIX] toLocaleString : new helper to use the locale's decimal separator [Task: 6232818](https://www.odoo.com/odoo/2328/tasks/6232818) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
German DATEV exports now correctly handle bank payments involving three different currencies, such as when the payer, bank account, and company currency differ. The export splits these settlements through the standard DATEV clearing account so each line uses only one foreign currency, reducing export errors while leaving normal transactions unchanged.
Original PR description
Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank…
Issue: - DATEV does not support multiple foreign currencies on a single journal line. - This can occur when reconciling a bank transaction where: - the payer uses one currency (C1), - the bank journal is held in another currency (C2), - the company uses a third currency (C3). - The existing export logic could not represent the bank liquidity and foreign AR/AP currencies separately in such cases. Fix: - Detect 3-currency cases from bank statement transactions and their liquidity line. - Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the transaction into two logical legs: - Bank → Clearing (bank journal currency) - AR/AP → Clearing (payer currency) - Emit the liquidity leg only once when multiple foreign AR/AP lines are reconciled against the same bank transaction. - Keep regular 1- and 2-currency transactions on the existing export path. Impact: - Correctly represents 3-currency bank settlements in DATEV. - Keeps each exported line in a single foreign currency. - Leaves manual entries and payment transactions outside this specific handling, as the scenario is specific to the bank liquidity line. taskID-5457547 Forward-Port-Of: odoo/enterprise#128665 Forward-Port-Of: odoo/enterprise#109010
This update corrects an internal logging issue in the Sign app so that error handling uses an available logger. It helps avoid avoidable failures when the system needs to record signing-related issues, improving reliability without changing user workflows.
Original PR description
See https://github.com/odoo/enterprise/pull/121960 Forward-Port-Of: odoo/enterprise#128748