Thursday, April 16, 2026
7 changes · saas-18.2
Resolved issues and error corrections
Replacing a styled image with an icon in the editor now removes image-only shape styling such as rounded corners, shadows, or thumbnail borders. This prevents icons from inheriting inappropriate visual effects and keeps edited content looking consistent.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258060
This fix avoids changing existing account links on tax groups when a chart of accounts is reloaded. It prevents reloads from causing accounting validation errors when account purposes and tax group settings no longer match.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This fixes demo data used by Peppol and Danish Nemhandel so their example workflows include the newly required response information. Business users evaluating or demonstrating these e-invoicing flows should no longer encounter unexpected errors in demo mode.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
Fixed broken image paths in website call-to-action snippets so they load consistently across all page levels. This prevents visual issues on deeper pages such as product pages and keeps promotional website sections looking correct.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#258879
Calendar popovers no longer show an unnecessary tooltip when users hover over a checkbox field. This prevents confusing raw HTML text from appearing and keeps the calendar details view cleaner.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259069 Forward-Port-Of: odoo/odoo#259011
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation in the barcode interface, preventing discrepancies in inventory tracking. This improves data reliability for warehouse operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#110241This update fixes a potential issue where the year for payroll reports was defaulting to the current year, causing test failures. The change ensures the correct year is always referenced, preventing future problems and maintaining accurate reporting. This improves the reliability of payroll calculations.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325