Friday, October 24, 2025
9 changes · saas-18.2
Resolved issues and error corrections
A website blog test now selects an archive month by its position instead of relying on the month name. This prevents the test from failing when the website uses a language where month names are translated differently.
Original PR description
Before this commit the blog_tags_with_date tour tried to select the October option by label. In other locales the month label differs and the tour could not find it, so the tour aborted at that step. Steps to reproduce: - Change the website language to one where October has another name. - Run the blog_tags_with_date preview tour. The tour now selects the first month option by index, independent of labels. runbot-233321 Forward-Port-Of: odoo/odoo#232610
Fixed-tax-only sales documents no longer fail when read through XML-RPC integrations. The tax totals now use a safe empty value instead of a non-transferable blank value, preventing integration errors for affected accounting workflows.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232517
The web test runner now handles cases where the Run button is clicked before all testing assets are fully loaded. This avoids a crash in manual test mode and makes internal testing more reliable for developers and quality teams.
Original PR description
Before this commit, in manual mode, "Run" could be clicked before the assets finished loading (and so, before the test runner was properly "ready"). This caused a crash because it tried to resolve a promise that did not exist yet. Steps to reproduce: - Go to test URL (manual) - Click "Run" as soon as the button is visible (probably via a script to make sure the click is fast enough) This commit fixes that by adding failsafes around that promise, effecitvely allowing to click "Run" early on. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232789
This fixes an internal website test so it no longer depends on optional demo data being present. The change helps keep automated quality checks stable across different test environments, reducing false failures during releases.
Original PR description
runbot-162894 Forward-Port-Of: odoo/odoo#213962
This update makes automated checks for two-factor authentication more stable by removing fragile timing assumptions in the test steps. It helps reduce intermittent test failures, giving teams more confidence that reported issues reflect real problems rather than test flakiness.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232958
The Cambodian localization package was updated to remove duplicate tax names that could block manual chart template installation. This helps businesses using the Cambodian accounting setup complete configuration reliably without tax-name conflicts.
Original PR description
Fixes an issue where some taxes in the Cambodian package have the same name, leading to errors when manually installing the chart template. Interestingly enough, the constraints does not trigger on the demo data company. Task [link](https://www.odoo.com/odoo/project.task/5194444) task-5194444 Forward-Port-Of: odoo/odoo#232968
The Field Service 'To Schedule' filter now excludes completed or cancelled tasks. This keeps the list focused on work that still needs scheduling or assignment, reducing confusion for dispatchers and planners.
Original PR description
**steps to reproduce:** Go to field service Go to all tasks > to schedule **issue:** The To Schedule filter was also displaying tasks in cancelled or done state, whereas it should only show open tasks that need to be scheduled or assigned. **cause:** The filter domain did not exclude cancelled/done state, causing closed tasks to appear in the filtered view. **fix:** Updated the filter domain to exclude cancelled/done state, to ensure only open tasks are shown under the To Schedule filter. task-5138590 Forward-Port-Of: odoo/enterprise#96600
This fix prevents an error when quality checks are used in manufacturing without the work order feature installed. It keeps quality point validation from referencing unavailable work order information, improving reliability for affected manufacturing setups.
Original PR description
**Issue:** The attribute operation_id for quality.point is defined in the mrp_workorder module. However, quality_mrp module does not list mrp_workorder in its dependencies. As a result in a system where quality_mrp is installed but mrp_workorder is not, the following error is raised when evaluating the constrain for quality points mesured on Operations. `"'quality.point' object has no attribute 'operation_id'"` **Proposed solution:** Override the constraint in quality_mrp_workorder to include conditions related to operation_id, ensuring that it is only evaluated when the field is available. Forward-Port-Of: odoo/enterprise#97338
Fixes a display issue in the Barcode app where decimal quantities could show too many digits after repeated scans. This keeps receipt quantities easier to read and helps warehouse users avoid confusion when processing inventory.
Original PR description
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54)…
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54) and mark it as To Do. - Open the Barcode app, open the corresponding receipt, and click the Edit button. - Increment the number of scans several times until you notice too many decimal digits (if you choose 10.54, you can test with 3). **Cause** A floating-point precision error occurs in the getter [`quantityToFulfill`](https://github.com/odoo/enterprise/blob/4b08734124c3bc84f7d95d170b39e9909e20d66b/stock_barcode/static/src/widgets/digipad.js#L55C9-L55C50), which is rendered directly [in XML templates](https://github.com/odoo/enterprise/blob/e8063141b33a9a8aa51d1ce94a66af313b2c1c89/stock_barcode/static/src/widgets/digipad.xml#L20C25-L21C89) without rounding. **Solution** Round the displayed value in the `quantityToFulfill` getter in the same manner than in [barcode_model](https://github.com/odoo/enterprise/blob/d4e5b69c7ea87fba3f2a5204ed6939b97879e4a8/stock_barcode/static/src/models/barcode_model.js#L99-L103). opw-5039796 Forward-Port-Of: odoo/enterprise#97475