Odoo Changelog — 2025-09-19

Friday, September 19, 2025

8 changes · 19.0

Bug Fixes(8)

Resolved issues and error corrections

[FIX] website_slides: prevent error when creating the attendee record.

Core19.0website_slides

Fixed an issue that could block users from creating new attendee records from the eLearning reporting views. This prevents an unexpected error and keeps attendee management working reliably.

Original PR description

Currently an error occurs when creating the attendee records.

Steps to Reproduce:

 - Install the `website_slide` module.
 - Go to `Reporting` > `Attendees`.
 - Go to either the `Graph or Pivot View` and click on any `count` value.
 - Open any attendee record and click on `New`.

`SyntaxError: syntax error at or near ")"
LINE 18: WHERE SCP.id IN ()
^`

This error occurs when creating an Attendee record. The _compute_next_slide_id
method runs every time the record is accessed, which causes the error [1].
As clearly mentioned in [this commit](https://github.com/odoo/odoo/commit/fd2fb88bb155b680147313433d22a2b7388c902c#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L292-R326), when a compute method is declared
without the @api.depends(...) decorator or with no actual dependencies,
the computed field will still be initialized when creating a new record
from a form view.

This commit ensures that when the compute method runs and the record
has not been created yet, the next_slide_id is set to False.

[1]:- https://github.com/odoo/odoo/blob/9f18013bc05e6657f5d41c05931fcdafad827d54/addons/website_slides/models/slide_channel.py#L91

sentry-6465821899

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

Forward-Port-Of: odoo/odoo#227733
Forward-Port-Of: odoo/odoo#217104

#elearning#attendees#reporting

[FIX] web: calendar year view resizing

PR #227832

Core19.0web

The calendar year view now handles browser resizing reliably by using FullCalendar's built-in resize handling instead of duplicating it. This helps users keep a properly adjusted yearly calendar layout when changing window size or device orientation.

Original PR description

FullCalendar already applies a debounce on the `windowResize` handler.

Thus, doing it again in our renderer is a duplicated effort.

Also, in the Year calendar renderer, the debounced version of the handler is initialized after the FullCalendar instances (one for each month) are created... which prevents it from being run at all.

This commit fixes and cleans this up by directly passing our handler to FullCalendar, letting him do the rest.

task-4809668

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

Forward-Port-Of: odoo/odoo#227725
Forward-Port-Of: odoo/odoo#227458

#calendar#year view#resizing

[FIX] project: hide 'Recurrent' field for archived tasks in project sharing view

PR #227833

Core19.0project

Archived tasks opened through project sharing now match the standard project view by hiding the Recurrent field. This prevents users from seeing an option that should not apply to inactive tasks, making the shared project experience more consistent.

Original PR description

**Steps to Reproduce:**
  - Share a project.
  - From the shared project, archive a task.
  - Open the archived task in the standard project form view → the Recurrent field becomes invisible (as expected).
  - Open the same archived task from the Project Sharing view by applying the Inactive/Archived filter → the Recurrent field is 
     still visible.

**Issue:**
The Recurrent field should not be visible for archived tasks. However, in the Project Sharing view, it still appears for inactive tasks.

**Current behaviour:**
The Recurrent field is hidden in the standard form view for archived tasks, but remains visible in the project sharing view.

**Expected behaviour:**
The Recurrent field should remain invisible in both the standard form view and the project sharing view when the task is archived.

**Fix:**
Adjusted the project sharing form view XML to apply the same invisible logic, ensuring the Recurrent field is hidden when the task is archived.

**Task-5040281**

Forward-Port-Of: odoo/odoo#226220

[FIX] industry_fsm: display 'Repeat Interval' block under 'Planned Date' block.

PR #95098

Enterprise19.0industry_fsm

Field Service task forms now show the repeat interval directly under the planned date. This makes recurring task settings easier to find and keeps related scheduling information together.

Original PR description

**Steps to Reproduce:**
1. Open the Field Service app.
2. Create or open an existing task.
3. Check the form view of the task.

**Issue:**
- The 'Repeat Every' block was displayed at the bottom of the sheet, making it 
  less intuitive.
- It should logically appear under the 'Planned Date' block for better visibility.

**Current behaviour:**
- The 'Repeat Every' block appears in a different section, away from the 
   'Planned Date' block.

**Expected behaviour:**
- The 'Repeat Every' block should be displayed directly under the 'Planned Date' 
  block for better usability and logical grouping.

**Fix:**
- Adjusted the form view XML to move the 'Repeat Every' field below the 
  'Planned Date' field.

**Task-5040281**

Forward-Port-Of: odoo/enterprise#93208

#field-service#task-scheduling#usability

[FIX] website_sale_subscription: adapt to community changes

PR #95078

Enterprise19.0website_sale_subscription

This update keeps the online subscription purchase flow aligned with recent changes in the main website sales system. It helps prevent display or checkout issues for customers buying subscriptions online.

#subscriptions#ecommerce#checkout

[FIX] l10n_it: Split payment tax group label fix

PR #227538

Core19.0l10n_it

Italian split payment taxes now show the correct label in the Taxes column of PDF documents instead of appearing like standard taxes. This helps customers and businesses read tax information accurately on generated documents.

Original PR description

Split payment taxes were not labelled correctly in the PDF's "Taxes" column, they were labelled as standard taxes.

<img width="1214" height="598" alt="image" src="https://github.com/user-attachments/assets/f1ea57bd-9a7f-460f-8c81-6a89585ba6d8" />

Forward-Port-Of: odoo/odoo#227284
Forward-Port-Of: odoo/odoo#226366

#italy#taxes#pdf#split-payment

[FIX] mail: fix 2 'Add a reaction' assertion error in HOOT test

PR #227888

Core19.0mail

This update fixes internal automated tests for the Mail app by making sure they select the correct "Add a reaction" button when two similar options are present. It helps keep message reaction functionality stable without changing the user experience.

Original PR description

Follow-up of https://github.com/odoo/odoo/pull/227728

PR above improved quick add a reaction to use quick reaction menu too, similarly to "Add a reaction" in the message actions.

By doing so, the 2 buttons to add a reaction have been adapted to use same label "Add a reaction", one was just "Add reaction".

Some HOOT tests were asserting presence of the "Add a reaction" button, but with the change there are sometimes 2 such buttons, one being the message action and the other is the quick add reaction. Tests were adapted but not all of them: when they expect to click on "Add a reaction" on a message with at least one reaction, it should clarify whether the "Add a reaction" is the one in message action or the one in quick add a reaction, otherwise the HOOT test fails due to attempting to click on the 2 buttons at once.

This commit fixes with more specific selector, that the "Add a reaction" to click is the one from message actions.

#tests#reactions#messaging

[FIX] core: Make `fetch()` more robust against invalid recordset

PR #227853

Core19.0core

This update prevents crashes when the system loads records in uncommon but possible situations, such as mixed temporary and saved records or records with an empty identifier. It improves reliability in the core data layer and makes behavior more consistent across Odoo.

Original PR description

This commit addresses two corner cases that cause `fetch()` to crash:

Mixing new and real records:
- Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`.
- Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM.

Using `False` as a record id:
- Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called.
- Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error.

Forward-Port-Of: odoo/odoo#227447

#stability#orm#record-loading

Currently an error occurs when creating the attendee records. Steps to Reproduce: - Install the `website_slide` module. - Go to `Reporting` > `Attendees`. - Go to either the `Graph or Pivot View` and click on any `count` value. - Open any attendee record and click on `New`. `SyntaxError: syntax error at or near ")" LINE 18: WHERE SCP.id IN () ^` This error occurs when creating an Attendee record. The _compute_next_slide_id method runs every time the record is accessed, which causes the error [1]. As clearly mentioned in [this commit](https://github.com/odoo/odoo/commit/fd2fb88bb155b680147313433d22a2b7388c902c#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L292-R326), when a compute method is declared without the @api.depends(...) decorator or with no actual dependencies, the computed field will still be initialized when creating a new record from a form view. This commit ensures that when the compute method runs and the record has not been created yet, the next_slide_id is set to False. [1]:- https://github.com/odoo/odoo/blob/9f18013bc05e6657f5d41c05931fcdafad827d54/addons/website_slides/models/slide_channel.py#L91 sentry-6465821899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227733 Forward-Port-Of: odoo/odoo#217104

FullCalendar already applies a debounce on the `windowResize` handler. Thus, doing it again in our renderer is a duplicated effort. Also, in the Year calendar renderer, the debounced version of the handler is initialized after the FullCalendar instances (one for each month) are created... which prevents it from being run at all. This commit fixes and cleans this up by directly passing our handler to FullCalendar, letting him do the rest. task-4809668 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 Forward-Port-Of: odoo/odoo#227725 Forward-Port-Of: odoo/odoo#227458

**Steps to Reproduce:** - Share a project. - From the shared project, archive a task. - Open the archived task in the standard project form view → the Recurrent field becomes invisible (as expected). - Open the same archived task from the Project Sharing view by applying the Inactive/Archived filter → the Recurrent field is still visible. **Issue:** The Recurrent field should not be visible for archived tasks. However, in the Project Sharing view, it still appears for inactive tasks. **Current behaviour:** The Recurrent field is hidden in the standard form view for archived tasks, but remains visible in the project sharing view. **Expected behaviour:** The Recurrent field should remain invisible in both the standard form view and the project sharing view when the task is archived. **Fix:** Adjusted the project sharing form view XML to apply the same invisible logic, ensuring the Recurrent field is hidden when the task is archived. **Task-5040281** Forward-Port-Of: odoo/odoo#226220

**Steps to Reproduce:** 1. Open the Field Service app. 2. Create or open an existing task. 3. Check the form view of the task. **Issue:** - The 'Repeat Every' block was displayed at the bottom of the sheet, making it less intuitive. - It should logically appear under the 'Planned Date' block for better visibility. **Current behaviour:** - The 'Repeat Every' block appears in a different section, away from the 'Planned Date' block. **Expected behaviour:** - The 'Repeat Every' block should be displayed directly under the 'Planned Date' block for better usability and logical grouping. **Fix:** - Adjusted the form view XML to move the 'Repeat Every' field below the 'Planned Date' field. **Task-5040281** Forward-Port-Of: odoo/enterprise#93208

Split payment taxes were not labelled correctly in the PDF's "Taxes" column, they were labelled as standard taxes. <img width="1214" height="598" alt="image" src="https://github.com/user-attachments/assets/f1ea57bd-9a7f-460f-8c81-6a89585ba6d8" /> Forward-Port-Of: odoo/odoo#227284 Forward-Port-Of: odoo/odoo#226366

Follow-up of https://github.com/odoo/odoo/pull/227728 PR above improved quick add a reaction to use quick reaction menu too, similarly to "Add a reaction" in the message actions. By doing so, the 2 buttons to add a reaction have been adapted to use same label "Add a reaction", one was just "Add reaction". Some HOOT tests were asserting presence of the "Add a reaction" button, but with the change there are sometimes 2 such buttons, one being the message action and the other is the quick add reaction. Tests were adapted but not all of them: when they expect to click on "Add a reaction" on a message with at least one reaction, it should clarify whether the "Add a reaction" is the one in message action or the one in quick add a reaction, otherwise the HOOT test fails due to attempting to click on the 2 buttons at once. This commit fixes with more specific selector, that the "Add a reaction" to click is the one from message actions.

This commit addresses two corner cases that cause `fetch()` to crash: Mixing new and real records: - Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`. - Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM. Using `False` as a record id: - Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called. - Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error. Forward-Port-Of: odoo/odoo#227447