Friday, August 28, 2026
12 changes · 18.0
Resolved issues and error corrections
Maintenance request activities now use the user's timezone when setting deadlines from scheduled dates. This prevents reminders from appearing one day early for users in timezones far ahead of UTC, improving scheduling accuracy.
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…
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-prRomanian SAF-T (D406) export files now show the correct required file version, 2.0, instead of 2.4.8. This helps businesses submit compliant accounting reports and avoid potential validation or filing 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
The Send to eTransport button is now shown when a Romanian stock transfer is ready as well as when it is completed. This lets users start the required eTransport reporting at the right operational stage instead of waiting until the transfer is done.
Original PR description
Currently, the Send to eTransport button on `stock.picking` is only visible when picking is done. This PR fixes this behaviour and makes it visible when picking is ready or done both. task-5930984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the internal tests that verify video meeting links are correctly included in calendar invitation files. It helps maintain reliability for online meeting invitations without changing the user-facing calendar experience.
Original PR description
Follow-up of #283562. PR above added the meeting's videocall_location as a URL property in generated iCalendar (.ics) invitation files. This commit clean the code of tests written in the forward-port (#283934).
Credit card and cash journals configured for file-based transaction imports now show the Import File button on the Accounting dashboard. This removes confusion and lets users import statements consistently across supported journal types.
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
New customer or vendor records created from sales or purchase orders now start as companies instead of individuals. This prevents avoidable validation issues during setup and makes the flow consistent with invoicing behavior.
Original PR description
When creating a new customer or vendor from a sale order or purchase order, the partner form can initially be created with company_type set to person. This can trigger constraints on stored fields before the user switches the partner type to Company. Set default_is_company=True in the partner field context for Sale and Purchase, matching the existing behavior in Account. This ensures newly created customers and vendors default to Company.
This fixes an issue where Odoo could use the wrong path separator when handling static files on Windows. It helps ensure static resources load correctly for Windows-based deployments without affecting normal use on other systems.
Original PR description
In commit 31aad6c, path normalization was added which also resulted in `/` being converted into `\` on Windows. There the `path.split('/')` did not work.
This commit changes the `'/'` to `os.sep` to fix the issue.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#285216This fix ensures product variant prices inherit the same minimum decimal display settings as their product templates. Reports and Studio customizations now show prices consistently, avoiding confusing differences such as 19.50 appearing as 19.5.
Original PR description
Issue: --- Record's `min_display_digits` is not inherited in case of a model inheritance. e.g. `list_price` is inherited to `product.product` from `product.template`, however it renders with fewer decimals than `product.template.list_price` in reports. Steps to reproduce: 1- Set a product's Sales Price to 19.5. 2- Add `product.product.list_price` to a report using studio. The variant's field renders with 1 decimal while `decimal.precision` is 2. Cause: --- This is missed in ee32a17495a10af18f0b5de0a295283c5059d3c2 which introduces minimum precision. opw-6465159
This fixes an issue where applying text color to a partial selection could color extra nearby text by mistake. The HTML editor now applies color only to the exact content selected, improving editing accuracy and preventing unintended formatting changes.
Original PR description
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…
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
Refreshing an X (Twitter) feed now handles invalid account tokens by disconnecting the affected account instead of showing a generic error. This prevents users from being blocked by unclear error messages and guides them toward reconnecting the account.
Original PR description
Bug === If the token because invalid, then an UserError is raised instead of disconnecting the account. This is because we "blind raise" all errors we get from X, instead of filtering the error linked to the stream configuration. Task-6499283 Forward-Port-Of: odoo/enterprise#129110
Users now see a more accurate message when requesting a migration in the French PDP configuration. This avoids misleading expectations from the previous “available tomorrow” timeline and makes the process clearer for everyone.
Original PR description
Currently when the user requested a migration, we don't show it in any way to the user, and the only timeline we give ("available tomorrow") is completely false. Because we don't have any field we could use for this client-side (maybe from 19.3 we can use the catch-all-json field) So just make the message same for everybody.
no-task
Forward-Port-Of: odoo/odoo#283594This fix prevents an unexpected error from appearing when Odoo prepares certain report actions. It improves reliability for users by ensuring the system uses the correct record context instead of failing with a traceback.
Original PR description
opw-6360013 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#274977