Thursday, September 4, 2025
11 changes · saas-18.2
Enhancements to existing features
This update makes automated tests for messaging and live chat use more stable page markers instead of visual styling details. It helps reduce false test failures and supports more reliable maintenance without changing the customer-facing product experience.
Original PR description
This commit updates the test selectors to use data-as-tab-id to avoid ambiguity. This change enhances the robustness of the tests by reducing their dependency on CSS classes. Using data-as-tab-id attributes provides a more stable and reliable way to select elements in the DOM for testing purposes. backport - https://github.com/odoo/odoo/pull/224974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225385
Resolved issues and error corrections
Interactive web tours now wait for the page action to finish updating before looking for the next item to click. This prevents tours from unexpectedly going backwards when a menu action changes the current view, making guided flows more reliable.
Original PR description
Step to reproduce: - Create a tour - Add a step that click on a menuitem on the systray with a view already opened - Then add a step that click on the search bar of the view Before this commit, if the step of a tour was triggering an action (e.g.: a menuitem) and that the next step's trigger was finding an element on the view before the action has finished to update the view, then the tour was backwarding because the found element diseppeared when the new action loaded the new view. Now, the tour interactive wait that the action manager finish to update the view to be sure the get the right element for the step trigger. ISSUE: https://github.com/odoo/odoo/issues/214652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220319
This fixes an issue where the Discuss welcome screen could appear inconsistently depending on how the page components loaded. The display decision is now handled from a shared source, making the experience more predictable for users.
Original PR description
Before this commit, whether to display the welcome view was based on a component state, so it was dependent on the lifecycle of components This commit changes the condition so that it relies on the store which should prevent inconsistent state. https://runbot.odoo.com/odoo/error/111051 Forward-Port-Of: odoo/odoo#225325
Fixes an issue where opening the technical Data view could fail when a record included custom field properties. Users can now inspect record data reliably in debug mode, supporting troubleshooting without unexpected errors.
Original PR description
Example Steps: - Install `crm` - Add a random field properties in a random form view - Enable debug mode - Open debug menu - Select Data - Traceback ```py raise ValueError(f"Invalid field…
Example Steps:
- Install `crm`
- Add a random field properties in a random form view
- Enable debug mode
- Open debug menu
- Select Data
- Traceback
```py
raise ValueError(f"Invalid field {field_name!r} on model {self._name!r}")
ValueError: Invalid field 'properties.xyz' on model 'x.y'
```
There are two causes for this problem.
First, we use orm.read to retrieve data from records, which does not directly handle sub-field properties. We only need to use `definition_property` (which contains the overall schema of the JSON field).
Second, when displaying the data, we use JSON.stringify with `replacer`:
```js
get content() {
const record = this.props.record;
return JSON.stringify(record, Object.keys(record).sort(), 2);
}
```
In this case, replace contains all the keys present in record, sorted. The problem is that the properties fields are themselves objects that contain the keys: `name`, `string`, `type`, `default`, `value`.
And giving an array to replace in `JSON.stringify` will filter the keys and keep only those that are whitelisted in it.
```js
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
const foo = {
foundation: “Mozilla”,
model: “box”,
week: 45,
transport: “car”,
month: 7,
};
JSON.stringify(foo, [“week”, “month”]);
// ‘{“week”:45,“month”:7}’, only keep ‘week’ and “month” properties
```
This will ignore the keys of the properties fields.
The fix is therefore to sort the object before stringifying it, without using replace.
Thanks to these two fixes, the data is displayed as expected, regardless of whether there are field properties or not.
opw-5017425
Forward-Port-Of: odoo/odoo#224084The wishlist checkout test now allows more time to complete, reducing false failures caused by slower test runs. This helps keep automated validation stable without changing the customer-facing wishlist experience.
Original PR description
Increase timeout for wishlist tour. As it was taking too long to complete. runbot-229616 Forward-Port-Of: odoo/odoo#224277 Forward-Port-Of: odoo/odoo#219653
This fixes an internal testing issue where some automated test runs could fail if no test tags were configured. It helps keep continuous integration checks reliable for teams using external test tooling.
Original PR description
Description of the issue/feature this PR addresses: The issue arises when using pytest (to get junit xml for CI) with [pytest-odoo==1.0.1](https://github.com/camptocamp/pytest-odoo) ``` run_tests def get_method_additional_tags(self, test_method): run_tests """Guess if the test_methods is a query_count and adds an `is_query_count` tag on the test run_tests """ run_tests additional_tags = [] run_tests > if 'is_query_count' in odoo.tools.config['test_tags']: run_tests E TypeError: argument of type 'NoneType' is not iterable run_tests run_tests ../custom/src/odoo/odoo/tests/common.py:778: TypeError ``` Info @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225496
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change default company for "marc demo" user to `(AR) Responsable Inscripto` - login with "marc demo" , go to shop page, and change site language to sapnish - add a product e.g, three set sofa to cart and goto checkout page - proceed and you will be directed to "Address management page" Observatio
Original PR description
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change…
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change default company for "marc demo" user to `(AR) Responsable Inscripto` - login with "marc demo" , go to shop page, and change site language to sapnish - add a product e.g, three set sofa to cart and goto checkout page - proceed and you will be directed to "Address management page" Observation: "Identification Type " and "AFIP Responsibility" are not translated Cause: After this commit [1], module l10n_ar_website_sale was dropped and address logic was mooved to l10n_ar and l10n_latam_base but the following pot files were not updated, this caused missing of tranlation in following modules [1] https://github.com/odoo/odoo/commit/5a93da8e9220ecbf664b26445b04717a9245ef5e Fix: Add missing translations in respective po and pot files Before: <img width="903" height="517" alt="image" src="https://github.com/user-attachments/assets/f1e265bd-e976-4698-b83b-9de821073b8c" /> After: <img width="806" height="374" alt="image" src="https://github.com/user-attachments/assets/a04dfde9-8e5d-4699-a1a4-1a8c36339f63" /> opw-5000512 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the Chilean POS localization where cash in/out operations could fail when a connected printer tried to print the receipt. This helps store staff complete cash movements smoothly without printer-related interruptions.
Original PR description
Before this commit, when a printer was connected, performing a cash in/out operation would raise an error when trying to print the receipt. opw-5060974
Fixed an issue where project budget indicators could show green even when an expense budget was exceeded. This helps users quickly identify overspending risks from the project dashboard.
Original PR description
**Step to reproduce:** - install "project_account_budget" - go to accounting > accounting > Analytic Budget - create a budget of type expense,say test budget - select analytic account `Asustek - Wood…
**Step to reproduce:**
- install "project_account_budget"
- go to accounting > accounting > Analytic Budget
- create a budget of type expense,say test budget
- select analytic account `Asustek - Wood Corner`
- set budget amount => 500. open the budget
- create a new project 'test project"> open setting > Analytic Page
- add `Asustek - Wood Corner` analytic account in project field
- create a PO with amount > 500
- in analytic distribution column, add `Asustek - Wood Corner` in project column
- confirm PO and create Bill
- Go to `test project` settings > Dashboard smart button
**Observation:**
- For exceeding expense budget, we have green color in budget section
- It should be red
**Cause:**
The conditional class for budget progress was incorrectly evaluated due to missing parentheses around the `and` condition.
In expressions like:
`(true and (1 == 1 ? 'a' : 'c')) or (1 == 1 ? 'b' : 'd') → 'a'` ✅
`true and 1 == 1 ? 'a' : 'c' or 1 == 1 ? 'b' : 'd' → 'b'` ❌
Without parenthesis, the `or` clause is evaluated unexpectedly, even when the `and` branch is intended to take precedence.
This commit wraps the `and` condition in parentheses to ensure the correct evaluation order and consistent class assignment.
Budget:
<img width="1203" height="291" alt="budget 4968162" src="https://github.com/user-attachments/assets/2d8223d5-0344-4ad0-b33c-2598ea167f2d" />
Before fix:
<img width="623" height="195" alt="before fix 4968162" src="https://github.com/user-attachments/assets/4ac749bf-fa93-4835-963a-5dfbdd05559d" />
After fix:
<img width="643" height="225" alt="after fix 4968162 " src="https://github.com/user-attachments/assets/4fd228f9-e32f-48d9-b6ef-55251b21d601" />
opw-4968162
Forward-Port-Of: odoo/enterprise#91617This fix updates an automated Planning test so it uses today’s date directly instead of relying on a dynamic function. It helps keep validation builds stable and reduces the risk of false test failures blocking releases.
Original PR description
Now the tour use edit with the date of today and not a function runbot build error: 164213 Forward-Port-Of: odoo/enterprise#93816
Documents no longer crash when a user tries to link a file to a type of record that has no existing entries, such as vehicles in a fresh Fleet setup. Instead, the system prevents that invalid linking action, keeping the document workflow stable and avoiding user-facing errors.
Original PR description
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet`…
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet` module(without Demo Data). 2) Open Documents App. 3) Upload a file in `Fleet` folder. 4) Select the uploaded file and click on `'Link to a vehicle'` button. Error: `ValueError: invalid literal for int() with base 10: 'False'` Root Cause: The `link_to_record` method attempts to find the first record of the target model to use as a default value when opening the linking wizard. If no records exist, the search returns an empty recordset, and accessing `.id` at [1], on it results in the value `False`. The code then incorrectly constructs a default reference string like `fleet.vehicle,False`. The wizard crashes when it tries to parse this string and convert the `False` part to an integer. Solution: This commit prevents error by ensuring that the user cannot link a document to a model without existing records. [1]- https://github.com/odoo/enterprise/blob/83640d21b2c31ed9d572c48e02a9aeea9eb1607b/documents/models/documents_workflow_rule.py#L113 sentry-6792079496 Forward-Port-Of: odoo/enterprise#93738 Forward-Port-Of: odoo/enterprise#91888