Monday, October 20, 2025
19 changes · saas-18.4
Enhancements to existing features
The website editor now detects when a browser cannot support image filters and disables that option instead of showing an error. This improves editing reliability for users on systems where WebGL is unavailable, such as some recent Chrome on Linux setups.
Original PR description
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported. Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters. This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable. task-5117584 Forward-Port-Of: odoo/odoo#232009 Forward-Port-Of: odoo/odoo#229705
Odoo now supports Uruguay's reduced VAT category for applicable sales, helping businesses meet local electronic invoicing and tax reporting requirements. The update adds the needed tax reporting grid and ensures reduced-rate VAT amounts are represented correctly in official tax data.
Original PR description
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and…
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).
1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra> (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact>
*Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231642
Forward-Port-Of: odoo/odoo#221073Uruguayan electronic invoices can now identify and report VAT rates outside the standard exempt, minimum, and basic rates. This improves tax declaration accuracy by including reduced-rate VAT totals in the official invoice XML and adding a dedicated tax grid for configuration.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#97223
Forward-Port-Of: odoo/enterprise#91392Point of Sale payment terminals connected through an IoT Box now use the same communication service as other IoT actions. This enables more connection methods, including WebRTC and websockets, which can improve reliability and responsiveness when processing payments.
Original PR description
As for any other actions sent from the db to the IoT Box, we updated payments terminals logic to use the `iot_http` service in order to allow them using webrtc and websocket in addition to longpolling. Backport of odoo/enterprise#92896 (`iot_http` service refactoring only, to allow listening without sending action) Backport of odoo/enterprise#96634 odoo/odoo#232282
Swedish batch payments can now include both international IBAN accounts and local BBAN, Bankgiro, or Plusgiro accounts in the same batch. When mixed account types are used, the system generates a ZIP file containing separate XML payment files, reducing manual splitting and making payment processing more flexible.
Original PR description
This commit add a new behaviour for batch payments in Sweden. Before this commit: batch payment with mixed payment for iban and bban/bankgiro/plusgiro wasn't allowed After this commit: now if the user create a batch payment with both type of account, we create a zip file with 2 xml files, one for iban and one for bban/bankgiro/plusgiro. Linked:https://github.com/odoo/odoo/pull/230104 [task-5107240](https://www.odoo.com/odoo/project/967/tasks/5107240) Forward-Port-Of: odoo/enterprise#97556 Forward-Port-Of: odoo/enterprise#95463
Luxembourg payroll parameters have been updated to reflect 2025 minimum social salary and related tax credit changes. This helps businesses calculate employee payroll more accurately and stay aligned with official Luxembourg requirements.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf task-5176255 Forward-Port-Of: odoo/enterprise#97468
Resolved issues and error corrections
Starshipit shipping requests now include the customer city or suburb information required by some carriers. This prevents supported services such as NZ Post Domestic from being incorrectly unavailable during shipping setup.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401 Forward-Port-Of: odoo/enterprise#97212
The customer preview for shared projects now matches what portal customers actually see. When billing is limited to validated timesheets, draft or unvalidated timesheets are no longer shown in the preview, reducing confusion and preventing misleading customer-facing information.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can check if project_sharing_id exist in context to filter timesheets. opw-5093339 Forward-Port-Of: odoo/enterprise#97470
This fix restores the bank account selection field when creating NACHA payments. It ensures users can choose the correct bank account, preventing payment setup issues for U.S. NACHA workflows.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996) Forward-Port-Of: odoo/enterprise#97319
This fix prevents marketing cards from being marked as synced when their image could not be generated, avoiding empty cards being treated as ready. It also ensures all cards tied to an updated campaign are marked for resync, so reused campaigns correctly refresh every selected card.
Original PR description
If wkhtmltoimage fails for any reason we currently keep going as if an image was actually rendered. Instead if the result of the image render is `None`, raise a generic error. This avoids issues with cards being marked "synced" even though they are actually empty. Additionally, when the campaign gets reused: - preview two records - update cards on a mailing - preview a record again - modify one of the fields on the card - update the cards on a mailing again - the card that was previewed is not updated ALL cards must require sync after a change to the campaign not just active ones. Otherwise they will keep their "synced" status and not be synced when they're selected for update later on. task-5048534 Forward-Port-Of: odoo/odoo#232005 Forward-Port-Of: odoo/odoo#224629
Point of Sale receipts, customer displays, and self-order payment pages now create QR codes directly in the browser. This prevents QR code printing or display issues when the POS is offline and keeps receipt layouts consistent.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228242
Restaurant owners can now print POS sales reports directly during an active session instead of needing to use the backend. This makes it faster and easier to review sales while operations are still running.
Original PR description
- Restaurants owners need to be able to print a sales report during a session. Before this commit, they were only available to print the report via the backend. task-id: 5076080 Forward-Port-Of: odoo/enterprise#94181
Ecuadorian XML vendor bills that include a discount now bring that discount into Odoo when imported. This prevents missing discounts on bills, helping accounting totals match the original XML document.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439
Point of Sale barcode scanning now uses the quantity encoded in GS1 barcodes instead of ignoring it. This helps cashiers add the correct product quantity automatically, reducing manual corrections and checkout errors.
Original PR description
Before this commit, the quantity encoded in a GS1 barcode was ignored when scanning. After this commit, the product will be added with the correct quantity extracted from the GS1 barcode. opw-5126522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232010 Forward-Port-Of: odoo/odoo#229678
Fixed an issue where a partial bank payment could incorrectly mark an installment invoice as fully paid and create an unnecessary suspense balance. Payments are now applied only up to the transaction amount, improving invoice payment accuracy and reconciliation reliability.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498 Forward-Port-Of: odoo/enterprise#96847
This fixes a crash that could happen when users synced fields in sales spreadsheets while using undo or redo. It helps keep spreadsheet-based sales workflows stable and avoids interruptions when reviewing or correcting changes.
Original PR description
Fix an issue where field sync would crash when used with UNDO/REDO. Task: 4854879 Forward-Port-Of: odoo/enterprise#92883
Grouping records by multi-select linked fields now follows the same visibility rules as the field itself. This prevents users from seeing groups for archived or filtered-out records, making list and reporting views more consistent.
Original PR description
Previously, grouping by a Many2many field did not consider either the field's domain or the field's context (that often contains `'active_test': False`). This caused inconsistent behavior in the web client: users would see groups related to archived Many2many records, even though these records weren't visible in the Many2many widget itself. This commit resolves the inconsistency by ensuring that both the field's domain and the field's context are respected when grouping by Many2many fields. backport of b0f3850aab0578791535e8a802e0ffd7790f3b45 task-4808679 Forward-Port-Of: odoo/odoo#230930 Forward-Port-Of: odoo/odoo#230582
Companies using the Turkey and Jordan accounting setups will again receive a default cash journal when they are initialized. This restores a compliance-related accounting setup that had been removed during earlier user interface cleanup work.
Original PR description
This commits adds back default cash journal for companies intializing with l10n_tr and l10n_jr. In our efforts to cleaning the UX/UI of accounting (PR #192031 task-4430969) We removed the default cash journal, however, some locatizations, such as l10n_tr and l10n_jo, require them for compliance reasons task-4991218 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232113 Forward-Port-Of: odoo/odoo#231200
This fix ensures the barcode app respects the delivery setting that blocks extra products when workers scan whole packages. It prevents unintended items from being added to deliveries and also makes package lines removable when needed, improving control during warehouse operations.
Original PR description
## Issue 1: "Allow Extra Products" option ignored for packages ### Steps to reproduce: - In the settings enable "Packages" - Go to Inventory > Configuration > Warehouse Management > Operation Types -…
## Issue 1: "Allow Extra Products" option ignored for packages
### Steps to reproduce:
- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
- 10 x P1 in a package PACK01
- 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.
### Cause of the issue:
The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the `barcode_allow_extra_product` option and creates its new lines via the private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671
### Fix:
Since scanning a package is expected to add all its content to the picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.
## Issue 2: impossibility of package line removal
### State of the art:
There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.
#### Steps to reproduce:
- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
- 10 units in package PACK01
- 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean
opw-4863621
opw-5080637
Forward-Port-Of: odoo/enterprise#97360
Forward-Port-Of: odoo/enterprise#96299