Odoo Changelog — 2025-06-23

Monday, June 23, 2025

30 changes · saas-18.2

Bug Fixes(5)

Resolved issues and error corrections

[FIX] core: compute_sudo for Properties

Coresaas-18.2coretest_new_api

This fixes cases where records could fail to save when property field definitions changed and the operation ran under a limited-access user. The system now applies default property values with the necessary permissions, preventing access errors during internal data flushing.

Original PR description

If the definition of the properties changes, the Properties fields is computed to add the default values from its definition. This is done in the `_compute` method when flushing data (because the field is stored). We need to run that method in sudo, because the default environment may have a user that doesn't have permissions to read the parent record or update the current record.

Example with `env` with public user which is the default_env for the transaction.
```
lead = env['crm.lead'].sudo().create({'name': 'test'})
lead.team_id = 2
```

Current behavior before PR:
Access error in:
```
  File "/opt/odoo/odoo/orm/fields_properties.py", line 294, in _compute
    {self.name: record[self.name], self.definition_record: record[self.definition_record]},
                ~~~~~~^^^^^^^^^^^
```

Desired behavior after PR is merged:
`lead` flushed correctly.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#properties#permissions#data-save

[FIX] point_of_sale: fix runbot 227554

PR #215361

Coresaas-18.2point_of_sale

This update fixes a timing issue that could cause automated Point of Sale checks to fail after a page refresh. It helps keep validation runs stable and reduces false failures during release testing.

Original PR description

Call to indexedDB is now debounced to avoid multiple calls, but when a tour refresh the page, the previous call is still pending and causes a failure in the test since the data are not in the database yet.

runbot error: 227554

#point of sale#testing#stability

[FIX] website_sale_wishlist: redirect to cart on empty wishlist

PR #215385

Coresaas-18.2website_sale_wishlist

Customers who add the last item from their wishlist to the cart are redirected to the cart again. This restores the expected shopping flow and avoids leaving shoppers on an empty wishlist page.

Original PR description

Versions
--------
- saas-18.2
- saas-18.3

Fix on master in FW.

Steps
-----
1. Add 1 item to your wishlist;
2. go to wishlist;
3. add item to cart.

Issue
-----
You don't get redirected to the cart.

Cause
-----
Commit c0f411cc7cf17 fixed an issue where products were removed from the wishlist before they were added to the cart via the product configurator by not passing a deferred redirect to `_removeWish`. An unintended side-effect is that the user no longer gets redirected when the wishlist is empty.

Solution
--------
After calling `_removeWish`, check if the wishlist is empty, and if so, call `_redirectNoWish` to restore previous behavior.

runbot-227042

#wishlist#cart#checkout#ecommerce

[FIX] l10n_se_sie4_export: handle account changes on tests

PR #86752

Enterprisesaas-18.2l10n_se_sie4_export

This fixes a recurring automated test failure in the Swedish SIE4 export caused by account setup differences when extra modules are installed. The export validation is now consistent across database configurations, reducing false failures in release checks.

Original PR description

From saas-18.2, some account changes on Swedish CoA when other module(s)
are installed have been breaking the test for the export (that exports
all the available account).

This commit adapts the expected test file to ignore this changes and
ensures the result always stays the same, no matter what modules are
installed on the database.

This fixes the currently recurring runbot errors from saas-18.2 and up:

[runbot-159821](https://runbot.odoo.com/odoo/error/159821)

#Sweden#accounting#tests#export

[FIX] hr_attendance_gantt: show gantt help on Empty records

PR #87874

Enterprisesaas-18.2hr_attendance_gantt

The Attendance Gantt view now shows its helpful empty-state guidance when there are no attendance records, even if a default employee row is present. This makes fresh databases clearer for users by explaining what to do instead of showing an empty-looking schedule.

Original PR description

Issue / current behavior:
In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default.

Required behavior:
The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records.

task-4874129

#attendance#gantt#empty-state#help

Other(25)

Miscellaneous changes

[FW][FIX] l10n_eg_edi_eta: duplicate compute

PR #215289

Coresaas-18.2l10n_eg_edi_eta

`l10n_eg_long_edi` is set by two different computes. This is completely useless as it will trigger a write and the actual compute will still be called when the field is read. Forward-Port-Of: odoo/odoo#215134

Original PR description

`l10n_eg_long_edi` is set by two different computes. This is completely useless as it will trigger a write and the actual compute will still be called when the field is read.

Forward-Port-Of: odoo/odoo#215134

[FW][FIX] l10n_es_edi_facturae: correct credit note facturae

PR #215205

If the definition of the properties changes, the Properties fields is computed to add the default values from its definition. This is done in the `_compute` method when flushing data (because the field is stored). We need to run that method in sudo, because the default environment may have a user that doesn't have permissions to read the parent record or update the current record. Example with `env` with public user which is the default_env for the transaction. ``` lead = env['crm.lead'].sudo().create({'name': 'test'}) lead.team_id = 2 ``` Current behavior before PR: Access error in: ``` File "/opt/odoo/odoo/orm/fields_properties.py", line 294, in _compute {self.name: record[self.name], self.definition_record: record[self.definition_record]}, ~~~~~~^^^^^^^^^^^ ``` Desired behavior after PR is merged: `lead` flushed correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Call to indexedDB is now debounced to avoid multiple calls, but when a tour refresh the page, the previous call is still pending and causes a failure in the test since the data are not in the database yet. runbot error: 227554

Versions -------- - saas-18.2 - saas-18.3 Fix on master in FW. Steps ----- 1. Add 1 item to your wishlist; 2. go to wishlist; 3. add item to cart. Issue ----- You don't get redirected to the cart. Cause ----- Commit c0f411cc7cf17 fixed an issue where products were removed from the wishlist before they were added to the cart via the product configurator by not passing a deferred redirect to `_removeWish`. An unintended side-effect is that the user no longer gets redirected when the wishlist is empty. Solution -------- After calling `_removeWish`, check if the wishlist is empty, and if so, call `_redirectNoWish` to restore previous behavior. runbot-227042

From saas-18.2, some account changes on Swedish CoA when other module(s) are installed have been breaking the test for the export (that exports all the available account). This commit adapts the expected test file to ignore this changes and ensures the result always stays the same, no matter what modules are installed on the database. This fixes the currently recurring runbot errors from saas-18.2 and up: [runbot-159821](https://runbot.odoo.com/odoo/error/159821)

Issue / current behavior: In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default. Required behavior: The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records. task-4874129

Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the field. Note that the default value and its presence in internal code of JS models happened for all tests that use `@mail` static files. That means this PR `[1]` fixed a retained memory for all `@mail` and related tests. While this fixed many tests, we still observed this retained memory on all discuss call tests. This happens because while the default value no longer uses this shared object, the computed value still does. Therefore call tests were sharing the const and thus retaining the window object. Note that the computed method is implicitly lazy, so this is only invoked in code that actually uses this `iceServers` field, hence why only discuss call tests were still affected by the issue. This commit fixes the issue by replacing the DEFAULT_ICE_SERVERS object by GET_DEFAULT_ICE_SERVERS function. This ensures each test use a different object, thus preventing retaining the window object after test has ended. [1]: https://github.com/odoo/odoo/pull/204521 Forward-Port-Of: odoo/odoo#215208

Following non-deterministic test failure happens on runbot: ``` [HOOT] Test "@mail/message/message/Can edit message comment in chatter" failed: [HOOT] Error: Failed to find 1 of ".o-mail-Message .o-mail-Composer-input" with value "edited again" (Timeout of 3 seconds). Found 0 instead. ``` We couldn't reproduce in practice to see why this fails, and we are not helped from HOOT tests on runbot being run in headless mode thus screenshots are useless. One theory of failure is race condition of composer input still containing the trailing `\n` character when we'd expect it to be removed. The `contains({ value })` of mail test helpers checks for exact match of value thus the error. This commit attempts to fix the issue by using relaxing the condition for input containing at least the expected character. In other words: it replaces the `{ value }` (exact match) by `:value()` (includes match). That way if the value still has the `/n` trailing character, assertion `edited again` would pass with `edited again/n`. Note that `:value` seems to not see newlines `\n` in inputs. This is a bit annoying so we had to relax the other value assertion too. There's plan to use web selectors rather than mail ones, which is another reason to not improve mail_test_helpers further and instead put effort to migrate to web test helpers. runbot-181952 Forward-Port-Of: odoo/odoo#214626

Steps to reproduce: - Install payroll, l10n_mx_hr_payroll (mexican localisation) - Install l10n_mx_hr_payroll_account - Switch to a Mexican Company - Create a payslip for a mexican employee with amount < 4000 - Compute the sheet for the payslip Error message appears, this error message is not a descriptive to the user or not telling what could have gone wrong. This happens because the mexican pay structure has some salary rules that has to be computed, one of these rules is `Retirement, assault in elderly and old age (CEAV) IMSS (Employer)` that has mode of code. This mode means calling safe_eval on the code raw text of it written in the xml file on the data folder. This rule aims to find the suitable taxation level to be applied on the salary. It reads the limits of each level and check if the `integrated_daily_wage` of the employee falls in this level and applies that taxation level. There is no upper limit on the salary, But there is a min level, hence if the integrated_daily_wage < mdw (minimum daily wage) the function returns None that used as index in the taxation table leading to an unreadable Exception from the safe_eval call. https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120 opw-4576482 Forward-Port-Of: odoo/enterprise#83364

Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6) Now, try to click on the Create Draft Entry **Error:** A traceback will occur. ``` ValueError: Expected singleton: res.company(1, 2) ``` **Cause:** When the user created multiple payslips with multiple companies containing the same batch and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, and try to change the state to Done using the action_payslip_done method. https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70 So the self will contain multiple payslip recordsets with different company in each payslip. This leads to the above traceback when accessing company_id from self https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61 **Solution:** In payslips, the company_id field should be in readonly state, since the value of the company_id will computed from the employee_id which is a required field. Also raised a validation Error for the previously created record to handle the traceback. Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763 opw-4797089 Forward-Port-Of: odoo/enterprise#87306 Forward-Port-Of: odoo/enterprise#86628

Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration. - Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic. - There will appear a red ribbon on the right corner that says “In need of action” - In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup” - Run this action manually Issue: Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address Note: This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses. Cause: When running the cron, the recipients aren't in the options Solution: Add an helper to find all necessary recipients from the template if no recipient ids in the options opw-4527398 Forward-Port-Of: odoo/enterprise#86916 Forward-Port-Of: odoo/enterprise#83944

Bug Fixes(5)

[FIX] core: compute_sudo for Properties

[FIX] point_of_sale: fix runbot 227554

[FIX] website_sale_wishlist: redirect to cart on empty wishlist

[FIX] l10n_se_sie4_export: handle account changes on tests

[FIX] hr_attendance_gantt: show gantt help on Empty records

Other(25)

[FW][FIX] l10n_eg_edi_eta: duplicate compute

[FW][FIX] l10n_es_edi_facturae: correct credit note facturae

Bug Fixes(5)

[FIX] core: compute_sudo for Properties

[FIX] point_of_sale: fix runbot 227554

[FIX] website_sale_wishlist: redirect to cart on empty wishlist

[FIX] l10n_se_sie4_export: handle account changes on tests

[FIX] hr_attendance_gantt: show gantt help on Empty records

Other(25)

[FW][FIX] l10n_eg_edi_eta: duplicate compute

[FW][FIX] l10n_es_edi_facturae: correct credit note facturae

[FW][FIX] core: attempt to reconnect to replica after 20min

[FW][FIX] web: user menu text overlapping checkbox

[FW][FIX] web: fix daterange selection when clicking start date

[FW][IMP] l10n_mx: DIOT 2025 rework

[FW][FIX] mail: fix retained memory in discuss call tests

[FW][FIX] l10n_tr_nilvera_einvoice: exclude ID without schemeID

[FW] PRHOOT 33

[FW][FIX] account: fix compute payment state

[FW][FIX] html_editor: avoid `nbsp` on pasting plain text in code blocks

[FW][FIX] resource: fully-flexible attendance hours

[FW][FIX] mail: attempt fixing runbot error 181952

[FW][FIX] project: wrong group for task_count field of project milestone

[FW][IMP] l10n_mx_hr_payroll: improve error msg for CEAV rule failure

[FW][FIX] account_invoice_extract: fix partner name matching for CIs

[FW][FIX] hr_payroll: make the company_id as readonly in payslip

[FW][FIX] account_reports: Integer rounding in VIES summary report

[FW][IMP] pos_urban_piper: online order ticket screen mobile view

[FW][REV] documents_account: prevent duplication of invoice document

[FW] PRHOOT 33

[FW][FIX] account_followup: recipients cc template in followup report

[FW][FIX] l10n_be_reports: prevent import crash in contacts due to tag access check

[FW][IMP] l10n_mx_reports, l10n_mx_xml_polizas: DIOT 2025 rework

[FW][IMP] account_reports: analyze tables in `test_balance_sheet_balanced`