Odoo Changelog — 2026-08-17

Monday, August 17, 2026

5 changes · saas-18.3

Bug Fixes(5)

Resolved issues and error corrections

[FIX] account_online_synchronization: avoid empty domain for bank rec widget

Enterprisesaas-18.3account_online_synchronization

When online bank synchronization finds no new transactions, the reconciliation screen now stays empty instead of showing transactions from all bank journals. This prevents users with multiple bank journals from seeing unrelated transactions and reduces confusion.

Original PR description

Currently, when we fetch zero transaction for an online account through bank synchronization, we open the bank reconciliation view with an empty domain, thus showing every transactions from every journals. This is confusing for the user if they have several bank journals.

This commit now shows an empty bank reconciliation widget if no transactions are fetched. Additionally, this aligns with how it works in Odoo 19.

[opw-6384718](https://www.odoo.com/mail/message/1138570272)

Forward-Port-Of: odoo/enterprise#127833

#bank synchronization#bank reconciliation#transactions

[FIX] mail: cleanup post data

PR #282264

Coresaas-18.3mailtest_discuss_full

This change sanitizes some post data before allowing the post, making sure the data received by `message_post` is clean based on the current user. part of task-6452761 Forward-Port-Of: odoo/odoo#280894

Original PR description

This change sanitizes some post data before allowing the post, making sure the data received by `message_post` is clean based on the current user.

part of task-6452761

Forward-Port-Of: odoo/odoo#280894

[FIX] mail: cleaning thread data

PR #282265

Coresaas-18.3mailtest_mailtest_mail_full

This change cleans up the requested data from `/mail/thread/data` route, ensuring it aligns with what is actually needed depending on the user and thread. part of task-6452761 Forward-Port-Of: odoo/odoo#280713

Original PR description

This change cleans up the requested data from `/mail/thread/data` route, ensuring it aligns with what is actually needed depending on the user and thread.

part of task-6452761

Forward-Port-Of: odoo/odoo#280713

[FIX] account: resolve RecursionError in discount allocation computation

PR #282447

Coresaas-18.3account

Original PR description

**Steps to reproduce:** 1. Install Accounting 2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments) 3. Test the imported records **Issue:** - `RecursionError:…

**Steps to reproduce:**
1. Install Accounting
2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments)
3. Test the imported records

**Issue:**
- `RecursionError: maximum recursion depth exceeded`.

**Cause:**
- In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`.
- While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`).
- By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop.

**Fix:**
1. Revert the assignment iteration back to `for line in self:`.
2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`.

By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion.

opw-6451854

Forward-Port-Of: odoo/odoo#282050

[FIX] html_editor: don't distribute table color to nested table cells

PR #281761

Coresaas-18.3html_editor

Original PR description

Problem: 
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.

Cause: 
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.

Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.

Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.

opw-6438972

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

Forward-Port-Of: odoo/odoo#281413

Currently, when we fetch zero transaction for an online account through bank synchronization, we open the bank reconciliation view with an empty domain, thus showing every transactions from every journals. This is confusing for the user if they have several bank journals. This commit now shows an empty bank reconciliation widget if no transactions are fetched. Additionally, this aligns with how it works in Odoo 19. [opw-6384718](https://www.odoo.com/mail/message/1138570272) Forward-Port-Of: odoo/enterprise#127833

**Steps to reproduce:** 1. Install Accounting 2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments) 3. Test the imported records **Issue:** - `RecursionError: maximum recursion depth exceeded`. **Cause:** - In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`. - While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`). - By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop. **Fix:** 1. Revert the assignment iteration back to `for line in self:`. 2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`. By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion. opw-6451854 Forward-Port-Of: odoo/odoo#282050

Problem: When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value. Cause: `table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells. Solution: Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells. Steps to reproduce: 1. Add a `background-color` to an outer `table`. 2. Nest a `table` with a different `background-color` inside one of its cells. 3. Load/normalize the content in the editor. 4. Observe both tables' cells carry the outer table's color. opw-6438972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281413