Daily updates from Odoo
Thursday, September 18, 2025
10 changes · saas-18.4
Enhancements to existing features
Accounting KPI summaries now include posted bank journal entries tied to unreconciled bank statements. This gives businesses a more complete view of outstanding bank activity and helps prevent understated accounting indicators.
Original PR description
### [REF] account: reorganize kpi.provider tests The account test_kpi_provider was already getting complicated, and this commit aims to simplify it by breaking it into smaller tests that show more clearly what is expected. Task-id: 5062431 ### [IMP] account: make kpi.provider report unreconciled bank statements The `kpi.provider:get_account_kpi_summary` method should include posted moves of a bank journal that are related to an unreconciled bank statement. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227744 Forward-Port-Of: odoo/odoo#227605
Resolved issues and error corrections
Pasted tables with a header row from tools like ChatGPT are now normalized so the editor can handle them correctly. This prevents crashes or selection problems when users edit or delete rows in those tables, improving reliability for content editing.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. - This commit also replaces all the `<th>` elements with `<td>`. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
When users create a mass mailing and change the target audience model, favorite templates now refresh to show the right options. This helps users find and reuse the correct saved templates more reliably.
Original PR description
In mass_mailing, when creating a new mailing, the theme selector allows users to select base templates for their mailings. Users can also add their own model-specific templates by marking mailings as "Favorite"s, which will cause them to show up in model selectors if the template's target model matches the new mailing's target model. However, in some circumstances, changing the target model does not cause the available template mailings to update. This is due to the callback responsible for updating the templates not reading the model variable correctly, causing useRecordObserver to not being called every time it is updated. This commit fixes this issue, therefore causing favorite templates to be updated more reliably. task-5054968 Forward-Port-Of: odoo/odoo#227424
The automatic cleanup process will now skip documents that are linked to signed document records, avoiding background deletion errors. This keeps the system stable while still preventing users from manually deleting protected signed documents.
Original PR description
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment…
Currently an error occurs when auto vacuum tries to clear documents linked to `sign_document`. **Steps to replicate:** * Install `documents_sign` with demo data. * Go to documents > Move Employment contracts to trash * Trash > Try to to delete employment contract you will see error in terminal. Similarly error will be produced by the Auto-Vacuum process when it attempts to delete it after the configured deletion delay. **Error:** `ForeignKeyViolation: update or delete on table 'ir_attachment' violates foreign key constraint 'sign_document_attachment_id_fkey' on table 'sign_document' DETAIL: Key (id)=(1164) is still referenced from table 'sign_document'.` **Root cause:** * At [1], the `sign.document` model was introduced, which prevents the deletion of sign documents. As a result, attempting to delete them due to [2] will cause an error. **Solution:** * Update the `_get_gc_clear_bin_domain` to ensure that the Auto-Vacuum process skips sign documents. * This will still throw an Validation and ForeignKey error as expected when the user tries to delete it from the GUI letting them know it cannot be deleted. [1]: https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b#diff-deebbcccf829fd1804d145c5c7140b482801644bd948639f77caa310b18b8120 [2]: https://github.com/odoo/enterprise/blob/828d47f9ad1d5e396b074c404287799574a6d692/sign/models/sign_document.py#L44 sentry-6842360375 Forward-Port-Of: odoo/enterprise#93818
Changing a customer’s country could crash checkout when the same shopper had reward-enabled carts open on multiple websites. This fix lets Odoo update pricing and loyalty rewards across those carts correctly, avoiding an interruption to the shopping experience.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable…
Versions -------- - 16.0+ Steps ----- 1. Have 2 eCommerce sites; 2. have a user with an open cart in both sites; 3. have a reward applied in one or both of carts; 4. have a fiscal position applicable to the user's address; 5. change the user's country to one with a different fiscal position. Issue ----- > ValueError: Expected singleton: sale.order(1, 2) Cause ----- As of commit ede8846987a98, fiscal positions get recomputed on address changes. When a fiscal position changes, the `_recompute_prices` method gets called on all open carts. This method does not include an `ensure_one` check, so it should be able to handle multiple sales orders. However, the `sale_loyalty` override will call `_update_programs_and_rewards` on `self` if any reward line is encountered. This method does have an `ensure_one` check, leading to the error. Solution -------- Rewrite the override as a loop, so it can handle multiple records in `self`. opw-5017669 Forward-Port-Of: odoo/odoo#224225
Creating a new attendee record from eLearning reporting views no longer triggers an error. This prevents interruptions for users reviewing course attendees and keeps reporting workflows usable.
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…
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#217104
Enabling the Can Create option in Studio for Website Live Chat channels no longer triggers an error. This improves reliability for teams customizing Live Chat views and prevents interruptions when configuring channel settings.
Original PR description
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`,…
Currently, an error occurs when enabling `Can Create` in Studio for a Website Live Chat channels. **Steps to reproduce:** - Install the `im_livechat` and `web_studio` modules. - Go to `Live Chat`, create a new channel, then return to the Live Chat channels view and open the newly created channel in kanban view. - Open `Studio` and enable `Can Create`. **Error:** ``` SyntaxError: syntax error at or near ')' LINE 12: WHERE discuss_channel.id IN () ``` **Root Cause:** At [1], an `SQL query` is executed with `self.ids`, when `self.ids` is `empty`, this leads to an `error`. **Fix:** This commit prevents the error by updating `_get_last_messages` to check for `empty self.ids` and return an empty recordset early and also updates `_compute_duration` to safely handle cases where `record.create_date` is `False`. [1]: https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/mail/models/discuss/discuss_channel.py#L1404-L1421 sentry-6861438710
Archived tasks opened through project sharing now show the same fields as they do in the standard project view. This prevents users from seeing the Recurrent option when it no longer applies, reducing confusion and keeping task details 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**In Field Service task forms, the repeat interval is now shown directly under the planned date. This makes recurring task scheduling easier to find and keeps related planning details 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**
This change prevents certain internal performance tests from failing when their timing results vary unpredictably. It helps keep automated checks reliable without affecting customer-facing features.
Original PR description
These tests are non-deterministic, we should not fail when running them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227515 Forward-Port-Of: odoo/odoo#226278