Thursday, July 24, 2025
21 changes · saas-18.1
Enhancements to existing features
The e-invoicing module now includes the latest relevant Peppol participant identifier codes, including additions for France, the United Arab Emirates, and Latvia. This helps businesses exchange electronic invoices with more partners using current official standards.
Original PR description
Add new relevant codes from the Peppol code list. In particular new codes for FR, AE and LV. Source: https://docs.peppol.eu/edelivery/codelists/v9.2/Peppol%20Code%20Lists%20-%20Participant%20identifier%20schemes%20v9.2.json opw-4932979 Forward-Port-Of: odoo/odoo#219969 Forward-Port-Of: odoo/odoo#218419
The mail system now has safer ways to fully clean up and refresh its internal message state. This reduces side effects in automated tests and prepares the platform to recover more reliably if notification updates are missed for an extended period.
Original PR description
This commit adds `store.destroy()` to cleanly destroy the store, including ongoing reactive observers. This is useful to make sure no side-effect store among HOOT tests This commit adds `store.reset()`, to make the store fresh as at page load. This is in preparation to make store reset in case we miss notifications for a long time. https://github.com/odoo/enterprise/pull/85631
Resolved issues and error corrections
The VAT validation checkbox now appears correctly for Greek and Irish companies with valid VAT numbers, even when the country code differs from the VAT prefix. This helps businesses confirm intra-community VAT status reliably for those countries.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784 Forward-Port-Of: odoo/odoo#201630
Code cleanup and technical improvements
This update aligns the accounting reconciliation logic with the standard way Odoo checks for early payment discounts. It reduces duplicated logic, making the feature easier to maintain while preserving existing behavior for users.
Original PR description
Supersedes: - https://github.com/odoo/enterprise/pull/88374 (fix branch name to align with community PR) This is repeated code from what already exists in odoo community. OPW-4895365 See: [odoo/odoo#215615](https://github.com/odoo/odoo/pull/215615) Forward-Port-Of: odoo/enterprise#90210
Miscellaneous changes
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#81812
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#81812
Withholding tax journal items created during payment processing now correctly include the related partner. This helps accounting teams keep payment records complete and easier to reconcile or report on.
Original PR description
Fixes an issue where the partner is missing from the journal items generated by the withholding tax on payment system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218268
Fixed an issue where a failed company image download could trigger an additional error while being recorded. This helps ensure company creation through the mail plugin continues more reliably even when an image cannot be downloaded.
Original PR description
When logging a failed image download for a new company,
A traceback will appear.
[1]- https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L360
https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L342-L344
here, ``new_company_info`` is dictionary, but at [1] the code incorrectly accesses
``name`` as an attribute.
So, it will lead to the below traceback.
Traceback:
```
File "/home/odoo/src/odoo/addons/mail_plugin/controllers/mail_plugin.py", line 359, in _create_company_from_iap
_logger.warning('Download of image for new company %s failed, error %s', new_company_info.name, e)
AttributeError: 'dict' object has no attribute 'name'
```
sentry-6554480256
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206771Saving a blog post after removing all content now shows a clear validation message instead of triggering a system error. This prevents confusing failures for website editors and helps keep the editing experience stable.
Original PR description
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a…
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a new blog. - Click to open the newly created blog. - Remove any existing content (e.g., placeholder text like 'Start Typing...'). - Type `/column` and click on the 2-column option. - Click on the columns that appear — you’ll see a delete icon. - Delete all the columns, click Save and check the terminal. Error: `ParserError: Document is empty` The error occurs when all content in the blog is deleted, resulting in empty HTML content. During saving, `html.fromstring(lang_value)` [1] is called with `lang_value` being effectively empty, which leads to a `ParserError`. [1] - https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/web_editor/models/ir_ui_view.py#L126 This commit fixes the problem by catching the `ParserError` and raising a `ValidationError` when the HTML content is empty. sentry-5081806749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216790
This fix improves the reliability of restaurant point-of-sale order actions by ensuring the system can wait for order synchronization to finish when needed. It helps reduce intermittent automated test failures and lowers the risk of orders being processed before their latest state is fully synced.
Original PR description
This is a complement to the fix of runbot error 164215. We're introducing a feature for the `clickOrderButton` to allow it to wait for the sync to finish. Runbot error: 164215 (https://runbot.odoo.com/odoo/error/164215) Enteprise PR: https://github.com/odoo/enterprise/pull/84389
Google Address Autocomplete now treats authorization messages from Google as warnings instead of application errors. This helps teams focus on real system issues while still keeping visibility into external service configuration problems.
Original PR description
Currently in Google Address Autocomplete, a logger prints an error in the log; however, this error is coming from the external API. error: `This API project is not authorized to use this API.` This commit will use logger warnings instead of errors since this is not an error in the codebase. sentry-6407824887
Users could run into an error when adding sub-tasks after repeatedly clicking the My Deadline column before saving. The update prevents that column from being sorted where it cannot support sorting, allowing sub-tasks to be saved normally.
Original PR description
Currently, an error occurs when a user tries to add a sub-task and clicks multiple times on the `My Deadline` column (which is not stored) before saving. This prevents the user from successfully…
Currently, an error occurs when a user tries to add a sub-task and clicks multiple times on the `My Deadline` column (which is not stored) before saving. This prevents the user from successfully adding sub-tasks.
**Steps to produce:**
- Install the `project` module.
- Navigate to `Project > Tasks > All Tasks` and open any task.
- In the `Sub-tasks` page, unhide the `My Deadline` field.
- `Add a line` and click multiple times on `My Deadline`, then try to `save`.
**Error:**
`ValueError: Cannot convert project.task.my_activity_date_deadline to SQL because it is not stored`
**Root Cause:**
At [1] and [2], the field `my_activity_date_deadline` is a computed field with `store=False`, meaning it does not exist in the database. The view, however, incorrectly sets `options={allow_order: 1}` on the column, which causes Odoo to generate an `SQL ORDER BY` on this `non-stored` field.
[1] https://github.com/odoo/odoo/blob/dfdf1c43fd3f2a39c205ccf97f139c2e1fcd213e/addons/project/views/project_task_views.xml#L490
[2] https://github.com/odoo/odoo/blob/dfdf1c43fd3f2a39c205ccf97f139c2e1fcd213e/addons/project/views/project_task_views.xml#L535
This commit ensures the `My Deadline` field is no longer sortable by removing the `allow_order` option from its column definition, preventing `Value error` triggered by attempting to sort on a non-stored field.
sentry - 6604203533This fix prevents an error when a company is restored while the Timesheets app is installed. It helps administrators manage archived companies without interruption or system failures.
Original PR description
Currently, on unarchiving a company, raises an error when hr_timesheet is installed **Steps to Reproduce:** - Install `hr_timesheet` module. - Create a company, archive it and then unarchive it. **Error:** `KeyError: 2` **Root Cause:** since https://github.com/odoo/odoo/commit/22e9d822e8cab08114c006eb8c4054c4de0c40f2, the `session_info` method relies on `user_companies` at [1], which fetches only active company IDs via `_get_company_ids()`. When a company is unarchived, its ID is missing in the `allowed_companies` dictionary at [2], causing a KeyError. [1]- https://github.com/odoo/odoo/blob/d3482e32f7dbe273125de84f1bbc434ac3c9ffc3/addons/web/models/ir_http.py#L146 [2]- https://github.com/odoo/odoo/blob/d3482e32f7dbe273125de84f1bbc434ac3c9ffc3/addons/web/models/ir_http.py#L153 **Solution:** Add a check to initialize missing keys in the `allowed_companies` dictionary before updating it. Sentry-6251348500
This fixes an internal test setup issue by removing an unnecessary dependency from the live chat discussion test suite. It helps keep automated checks reliable without changing customer-facing functionality.
Original PR description
remove the dependency on `TestPortal` from `test_discuss_full`, as it is not needed. [runbot-226366](https://runbot.odoo.com/odoo/error/226366) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213161
This fixes an error that appeared when users opened Studio on a candidate record and chose to show invisible elements. Candidate forms now behave correctly in Studio, reducing disruption for HR and recruitment users.
Original PR description
To reproduce: ============== 1/ Go to the Candidate form view 2/ Pick any candidate 3/ Open Studio 4/ Click on "Show Invisible Elements" Problem: ========= A traceback occurs because the `hr.candidate` model was not included in the supported models list for showing invisible elements. Solution: ========== Add `hr.candidate` to the supported models to avoid the traceback and properly show invisible elements in Studio. opw-4886130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215777
This update makes an automated test for editing chatter messages more reliable by removing checks that depended on timing. It helps prevent false test failures without changing how users edit messages.
Original PR description
Before this commit, the "Can edit message comment in chatter" test could fail intermittently. The test performs three edits on the same message, and due to the asynchronous nature of the bus (mock server > websocket > worker bus service > subscribers), bus notification are received later than rpc results. The test was asserting composer content between edits, which is unnecessary and sensitive to race conditions. For example: - First edit is sent. - Second edit is sent. - First edit is received. - Third edit opens the composer with outdated content. This is unlikely to occur in practice. This commit resolves the issue by removing non essential composer assertions. fixes runbot-227618 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
Mexican POS global invoices now use the issue address configured on the sales journal when available, instead of defaulting to the company address. This ensures the official electronic invoice XML shows the correct place of issue, helping businesses avoid incorrect tax document details.
Original PR description
Steps to reproduce: [l10n_edi_extended] - setup up a mexican company - create a journal in which you define an issued address (different from your company) - setup your pos with newly created journal - Open a pos session - add a product - pay in cash with no customer - in the backend go into the orders - select the newly created order in the list view and click on the action "create global invoice" - in the order > cfdi: download the created xml Issue: The "Lugar de expedicion" will have the zip code of the company and not from the issued address one Cause: We only check for issue adress in account_move but not from orders. Global invoice is not only for invoices but also to account for sale (orders) made with petty cash Solution: We don't want to create a bridge module only for that. We check if the field is defined on `account.journal` opw-4802389 Forward-Port-Of: odoo/enterprise#86545
This fix ensures website and company fields in Documents are shown only to internal users when there is more than one website or company available. It prevents irrelevant or inappropriate fields from appearing for portal users while keeping internal users' document management screens accurate.
Original PR description
Fixes the visibility of the `website_id` and `company_id` fields. These fields other than hidden from non internal users, they should be visible to internal users only when multiple websites or multiple companies are available, respectively. Partial revert of: ddf102e5 task-4505668 Forward-Port-Of: odoo/enterprise#86181
This update fixes automated checks for Web Studio's report editor so they run correctly. It helps maintain product quality by ensuring future changes are validated reliably before release.
Original PR description
https://github.com/odoo/odoo/pull/210152
This change removes an unreliable automated test for a minor rental website interface behavior because it was causing inconsistent test results. It helps keep the overall validation process stable without affecting customer-facing rental functionality.
Original PR description
## Version 18.0 saas-18.1 Non existing test from saas-18.2 ## Issue Commit 2ee876f9409b0ea4bc859d9629362e390c25f6e3 tried to fix a16a25b6023d2d48ad5c00853728c1498509b5a5 but did not solve indeterminism in the newly created test. Since the test validates a non-critical UI fix and introduces complex indeterminism, we choose to remove it to preserve stability in OE’s global test suite. runbot-229884 Forward-Port-Of: odoo/enterprise#90168
This fix prevents a restaurant point-of-sale test from continuing before order changes have fully synced. It helps avoid false runbot failures and improves confidence that preparation display workflows are stable.
Original PR description
*: pos_restaurant_preparation_display The issue is in the `PreparationDisplayTourResto2` tour. 1. The changes are sent when clicking the Order button. 2. Switched directly to the floor screen. 3. Return to the order, then immediately click on the product. - [ISSUE] at this point, the sync is still happening. - Right after the product is added, the orderlines are replaced by the ones resulting from the sync in step 2. The solution is to ensure that before doing anything after sending the order for preparation, we wait for the sync to finish. Runbot error: 164215 (https://runbot.odoo.com/odoo/error/164215) Community PR: https://github.com/odoo/odoo/pull/207901
## Steps to reproduce: - Install **Timesheets** and **payroll** apps. - Create a copy of the (**Standard 40 hours/week**) working schedule but remove **Wednesday** working hours. - Create a new **employee**, and set his Working Hours to the newly created working schedule. - Create a new **_running_** **contract** for the newly created employee with the newly created working schedule. - Go to **Timesheets** app, and search for the newly created employee. - **Add a line** for a project and r
Original PR description
## Steps to reproduce: - Install **Timesheets** and **payroll** apps. - Create a copy of the (**Standard 40 hours/week**) working schedule but remove **Wednesday** working hours. - Create a new…
## Steps to reproduce: - Install **Timesheets** and **payroll** apps. - Create a copy of the (**Standard 40 hours/week**) working schedule but remove **Wednesday** working hours. - Create a new **employee**, and set his Working Hours to the newly created working schedule. - Create a new **_running_** **contract** for the newly created employee with the newly created working schedule. - Go to **Timesheets** app, and search for the newly created employee. - **Add a line** for a project and register 8 hours in each day from Monday to Saturday. - Switch the view to Day, Notice how for both Wednesday and Saturday, no overtime is shown. +08:00 should be shown for each as both are non-working days per the newly created working schedule. **(Issue 2)** ## Investigation: - The overtime text comes from https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.xml#L8 using `overtimeIndication()` getter https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L34 - For the off days - (Wed, Sat, Sun) in our example -, the `allocated_hours` (`this.props.allocated_hours`) = ZERO - And so `shouldShowHours()` returns `false` https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L19-L21 - which makes `overtimeIndication()` returns null. That's why no overtime text is shown for off-days - Note that `allocated_hours` is `undefined` for rows that represent employee hours of the current week opw-3718279 Forward-Port-Of: odoo/enterprise#66528 Forward-Port-Of: odoo/enterprise#60048