Odoo Changelog — 2026-08-31

Monday, August 31, 2026

5 changes · saas-18.4

Bug Fixes(5)

Resolved issues and error corrections

[FIX] html_editor: only target fully selected nodes when applying color

Coresaas-18.4html_editor

This fix ensures that applying text color in the HTML editor affects only the exact selected text, even when the selection crosses styled text. It prevents unintended coloring of nearby bold or inline content, improving editing accuracy for users.

Original PR description

Problem: When applying color on a selection that spans across partially selected inline elements (e.g. `a[bc]d`), container elements whose contents are not fully selected (such as…

Problem:
When applying color on a selection that spans across partially selected inline elements (e.g. `<p><b>a[b</b>c]d</p>`), container elements whose contents are not fully selected (such as `<b>`) were included in `targetedNodes`. This caused improper color formatting/nesting on partially selected elements.

Cause:
In `ColorPlugin._applyColor()`, `targetedNodes` were filtered by checking `isNodeEditable(node)` and `nodeName !== "T"`, but did not check whether the contents of `node` were fully selected (`areNodeContentsFullySelected(node)`). As a result, partially selected ancestor elements were included in `targetedNodes`.

Solution:
Filter `targetedNodes` in `_applyColor()` using
`this.dependencies.selection.areNodeContentsFullySelected(node)` to ensure only fully selected nodes are targeted when applying colors.

Steps to reproduce:
1. Open html_editor.
2. Insert content: `<p><b>ab</b>cd</p>`.
3. Select `b` inside `<b>` and `c` inside `<p>` (`<p><b>a[b</b>c]d</p>`).
4. Apply text color (e.g. red).
5. Observe "ab" and "c" was colored instead of just "b" and "c".

task-6456443

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

Forward-Port-Of: odoo/odoo#285337
Forward-Port-Of: odoo/odoo#281462

#html editor#text formatting#color

[FIX] calendar: export videocall_location as URL in ICS files

PR #285258

Coresaas-18.4calendar

Calendar invitation files now include the meeting video call link in a standard URL field. This helps recipients and calendar apps surface the online meeting link more reliably when opening or importing invitations.

Original PR description

Add the meeting's videocall_location as a URL property in generated iCalendar (.ics) invitation files.


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

Forward-Port-Of: odoo/odoo#283934
Forward-Port-Of: odoo/odoo#283562

#calendar#ics#video calls#invitations

[FIX] l10n_ro_saft: set correct SAF-T (D406 Declaration) file version

PR #129764

Enterprisesaas-18.4l10n_ro_saftl10n_ro_saft_stock

Romanian SAF-T (D406) exports now use the correct declared file version, changing it from 2.4.8 to 2.0. This helps ensure generated reports match the expected regulatory format and reduces the risk of filing validation issues.

Original PR description

**Steps to reproduce:**
- Install the `l10n_ro_saft` module and switch to the RO Company.
- Navigate to Accounting > Reporting > General Ledger.
- Click the gear icon > SAF-T (D406 Declaration).
- Open the generated XML file and check the `AuditFileVersion` node.

**Observation:**
The `AuditFileVersion` node is set to `2.4.8`.

**Expected behavior:**
The `AuditFileVersion` node should be set to `2.0` 
(confirmed with the PO [1])

**Root Cause:**
At [2], the `file_version` value is incorrectly set to `2.4.8` 
instead of `2.0`.

[1]:
https://www.odoo.com/mail/message/1144385840

[2]:
https://github.com/odoo/enterprise/blob/ce2ad80c91aea27b143a80018aa73ed10d16cdbe/l10n_ro_saft/models/account_general_ledger.py#L179-L183

opw-6452918

Forward-Port-Of: odoo/enterprise#127935

#Romania#SAF-T#accounting#compliance

[FIX] account_bank_statement_import: import file on credit card journals

PR #129756

Enterprisesaas-18.4account_bank_statement_import

The Accounting dashboard now shows the Import File button for credit card and cash journals when file import is configured. This removes a confusing gap where these journals supported file imports but users could not start the import from their dashboard card.

Original PR description

The "Import File" button on the dashboard card only shows up for bank
journals. Credit card journals are treated the same way as bank journals
pretty much everywhere else: the dashboard card itself, the statements list,
the "Transaction Feeds" setting on the journal form (where you can pick the
file import option), and even `create_document_from_attachment` in this
module, which already accepts them. So you end up with a credit card journal
set to import files but nothing on its card to actually do it, and people
assume the feature is simply not there.

Show the button on credit card journals too.

Steps to reproduce:
- Install account_bank_statement_import_csv (or any other import format)
- Create a "Credit Card" journal and set its Transaction Feeds to the file import option
- Go to the Accounting dashboard
- The bank journal card has an "Import File" button, the credit card one doesn't

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

Forward-Port-Of: odoo/enterprise#129546

[FIX] maintenance: use user timezone for activity deadline

PR #285446

Coresaas-18.4maintenance

Maintenance activities now use the user's timezone when setting deadlines from scheduled dates. This prevents requests scheduled for tomorrow from incorrectly showing an activity deadline of today for users in timezones far ahead of UTC.

Original PR description

Steps to reproduce:
===============
- Install `maintenance` module
- Set your user's timezone to Pacific/Auckland (UTC+12/+13).
- Go to Maintenance > Maintenance Requests > New.
- Set the Scheduled Date to tomorrow morning (e.g. 8:00 am).
- Save and check the auto-generated activity in the chatter.

Issue:
====
The activity generated for the maintenance request's Scheduled Date is
created with a deadline of Today instead of Tomorrow, even though the
Scheduled Date was explicitly set to Tomorrow.

Cause:
=====
`schedule_date` is a `Datetime` field, always stored in UTC. In
`MaintenanceRequest.activity_update()`, the deadline for the activity
(a `Date` field) was computed with:
```py
    fields.Datetime.from_string(request.schedule_date).date()
```
`from_string()` only parses the stored value; it does not convert it
to any timezone. Calling `.date()` on it therefore truncates the raw
UTC datetime directly, ignoring the timezone of the user who picked
the date.

For a user ahead of UTC by a large enough offset (e.g. Pacific/Auckland,
UTC+12/+13), picking "Tomorrow 8:00 am" in their local timezone can
resolve to a UTC instant that still falls on Today's date (Tomorrow
8:00 local minus 13 hours lands at 19:00 UTC on Today). Truncating
that UTC value straight to a date silently shifts the deadline back
by one full day versus what the user selected.

Fix:
===
The deadline is now computed from the schedule date after converting
it to the record's (user's) timezone, using
`fields.Datetime.context_timestamp()`, instead of truncating the raw
UTC value. This fixes the reported issue for any user whose timezone
offset makes the truncation land on the wrong side of midnight UTC.

---

Note - automatic activity creation is remove from this [commit](https://github.com/odoo/odoo/commit/ab63e9709d8ea790a8a72a0a86b8bccc478c02d5) in saas-19.2

---

opw-6363868



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

Forward-Port-Of: odoo/odoo#275330

Problem: When applying color on a selection that spans across partially selected inline elements (e.g. `a[bc]d`), container elements whose contents are not fully selected (such as ``) were included in `targetedNodes`. This caused improper color formatting/nesting on partially selected elements. Cause: In `ColorPlugin._applyColor()`, `targetedNodes` were filtered by checking `isNodeEditable(node)` and `nodeName !== "T"`, but did not check whether the contents of `node` were fully selected (`areNodeContentsFullySelected(node)`). As a result, partially selected ancestor elements were included in `targetedNodes`. Solution: Filter `targetedNodes` in `_applyColor()` using `this.dependencies.selection.areNodeContentsFullySelected(node)` to ensure only fully selected nodes are targeted when applying colors. Steps to reproduce: 1. Open html_editor. 2. Insert content: `abcd`. 3. Select `b` inside `` and `c` inside `` (`a[bc]d`). 4. Apply text color (e.g. red). 5. Observe "ab" and "c" was colored instead of just "b" and "c". task-6456443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285337 Forward-Port-Of: odoo/odoo#281462

Add the meeting's videocall_location as a URL property in generated iCalendar (.ics) invitation files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283934 Forward-Port-Of: odoo/odoo#283562

**Steps to reproduce:** - Install the `l10n_ro_saft` module and switch to the RO Company. - Navigate to Accounting > Reporting > General Ledger. - Click the gear icon > SAF-T (D406 Declaration). - Open the generated XML file and check the `AuditFileVersion` node. **Observation:** The `AuditFileVersion` node is set to `2.4.8`. **Expected behavior:** The `AuditFileVersion` node should be set to `2.0` (confirmed with the PO [1]) **Root Cause:** At [2], the `file_version` value is incorrectly set to `2.4.8` instead of `2.0`. [1]: https://www.odoo.com/mail/message/1144385840 [2]: https://github.com/odoo/enterprise/blob/ce2ad80c91aea27b143a80018aa73ed10d16cdbe/l10n_ro_saft/models/account_general_ledger.py#L179-L183 opw-6452918 Forward-Port-Of: odoo/enterprise#127935

The "Import File" button on the dashboard card only shows up for bank journals. Credit card journals are treated the same way as bank journals pretty much everywhere else: the dashboard card itself, the statements list, the "Transaction Feeds" setting on the journal form (where you can pick the file import option), and even `create_document_from_attachment` in this module, which already accepts them. So you end up with a credit card journal set to import files but nothing on its card to actually do it, and people assume the feature is simply not there. Show the button on credit card journals too. Steps to reproduce: - Install account_bank_statement_import_csv (or any other import format) - Create a "Credit Card" journal and set its Transaction Feeds to the file import option - Go to the Accounting dashboard - The bank journal card has an "Import File" button, the credit card one doesn't --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#129546

Steps to reproduce: =============== - Install `maintenance` module - Set your user's timezone to Pacific/Auckland (UTC+12/+13). - Go to Maintenance > Maintenance Requests > New. - Set the Scheduled Date to tomorrow morning (e.g. 8:00 am). - Save and check the auto-generated activity in the chatter. Issue: ==== The activity generated for the maintenance request's Scheduled Date is created with a deadline of Today instead of Tomorrow, even though the Scheduled Date was explicitly set to Tomorrow. Cause: ===== `schedule_date` is a `Datetime` field, always stored in UTC. In `MaintenanceRequest.activity_update()`, the deadline for the activity (a `Date` field) was computed with: ```py fields.Datetime.from_string(request.schedule_date).date() ``` `from_string()` only parses the stored value; it does not convert it to any timezone. Calling `.date()` on it therefore truncates the raw UTC datetime directly, ignoring the timezone of the user who picked the date. For a user ahead of UTC by a large enough offset (e.g. Pacific/Auckland, UTC+12/+13), picking "Tomorrow 8:00 am" in their local timezone can resolve to a UTC instant that still falls on Today's date (Tomorrow 8:00 local minus 13 hours lands at 19:00 UTC on Today). Truncating that UTC value straight to a date silently shifts the deadline back by one full day versus what the user selected. Fix: === The deadline is now computed from the schedule date after converting it to the record's (user's) timezone, using `fields.Datetime.context_timestamp()`, instead of truncating the raw UTC value. This fixes the reported issue for any user whose timezone offset makes the truncation land on the wrong side of midnight UTC. --- Note - automatic activity creation is remove from this [commit](https://github.com/odoo/odoo/commit/ab63e9709d8ea790a8a72a0a86b8bccc478c02d5) in saas-19.2 --- opw-6363868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275330