Sunday, August 23, 2026
8 changes · saas-19.3
Enhancements to existing features
This update improves internal tests around marketing automation scheduled jobs, including cases where campaigns succeed or fail. It helps ensure automated marketing activities run reliably over time and reduces the risk of test loops masking scheduling issues.
Original PR description
Forward-Port-Of: odoo/enterprise#128874 Forward-Port-Of: odoo/enterprise#128522
Resolved issues and error corrections
This fixes an issue where converting certain decimal hour values into times could fail when the minutes rounded up to 60. The change correctly rolls those minutes into the next hour, preventing errors in calculations such as aggregated work hours while preserving normal behavior.
Original PR description
### Bug `odoo.tools.date_utils.float_to_time` builds the minutes with a rounding step: ```python return time(int(integral), int(float_round(60 * fractional, precision_digits=0)), 0) ``` When the…
### Bug
`odoo.tools.date_utils.float_to_time` builds the minutes with a rounding step:
```python
return time(int(integral), int(float_round(60 * fractional, precision_digits=0)), 0)
```
When the fractional part of the hour is high enough, `round(60 * fractional)`
rounds up to a full **60**, and `time(hour, 60)` is invalid:
```python
>>> float_to_time(16.9959)
ValueError: minute must be in 0..59, not 60
>>> float_to_time(8.999)
ValueError: minute must be in 0..59, not 60
```
Any hours value whose fractional part is ≥ ~0.9917 hits this — which happens
easily with computed/aggregated work-hour floats.
### Fix
Carry the rounded-up minute into the hour, and return `time.max` when that carry
reaches the end of the day (mirroring the existing `hours == 24.0` case):
```python
if minute == 60:
hour += 1
minute = 0
if hour >= 24:
return time.max
```
`float_to_time(16.9959)` now returns `time(17, 0)`, `float_to_time(23.9959)`
returns `time.max`, and regular values are unchanged.
Adds `TestFloatToTime` in `test_date_utils.py` covering the carry, the
end-of-day carry, and regular values.
Forward-Port-Of: odoo/odoo#280807Mentioning a partner linked to multiple active users in a discussion sub-channel no longer causes an error. The system now checks each user’s notification preference and invites the partner when at least one linked user allows channel notifications, keeping collaboration flows uninterrupted.
Original PR description
Before this commit, mentioning a partner that has two active users in a sub-channel ended on: ValueError: Expected singleton: res.users.settings(77, 80) This happens because the channel notification setting is read through res_users_settings_id, a Many2one on res.users, so two users give two settings records and reading a value on them asks for a singleton. Only an administrator reaches it, as the res.users.settings rule limits everyone else to their own settings. This commit fixes the issue by inviting the partner as soon as one of its users did not turn channel notifications off. Forward-Port-Of: odoo/odoo#283912 Forward-Port-Of: odoo/odoo#283805
Fixed a crash that could occur when users reopened the note composer and pressed Escape or arrow keys in the “Continue with Full Composer?” popup. These keys now do nothing in that context, keeping the chatter workflow stable and preventing an unnecessary error screen.
Original PR description
Reproduction steps: - Open a record that has a chatter where you can log notes - Start logging a note in the composer - Close the composer - Click log note again - See "Continue with Full Composer?" popup - Hit escape, up, or down - See traceback This shouldnt really do anything, so this fix makes it do nothing instead of crashing. opw-6476660 Forward-Port-Of: odoo/odoo#283389 Forward-Port-Of: odoo/odoo#282803
This fix prevents errors when sales planning data is grouped by customer in setups where the customer field is not directly stored. It keeps planning and sales-related reporting reliable across different module configurations.
Original PR description
Before this commit, #122034 converted the related non-stored `partner_id` field in `planning.slot` into a compute non-stored field with a search method, the problem is that field was used as groupby inside a read_group which causes a traceback since the field is no longer reachable in SQL. This commit alters the groupby in problematic _read_group methods to use partner_id field when it is stored (when field service is installed) otherwise the groupby should be `sale_order_id.partner_id`. Forward-Port-Of: odoo/enterprise#128540
Opening the timesheet systray from a task now pre-fills the related project and task without changing the recorded time. This prevents users from accidentally losing an active timer value when logging time from task pages.
Original PR description
Before this commit, the prefill used when the user opens the timesheet systray when his current loaded page is a task, will alter the form view in the timesheet systray to set the project and task when those fields are unset. The problem is `unit_amount` is also given to 0 and so the timer is reset due to the prefill system. This commit makes sure the `unit_amount` field is not inside the prefill data to make sure the timer is no longer reset. opw-6481443 Forward-Port-Of: odoo/enterprise#128531
The Timesheet Assistant now clears the previous suggestion when a user unselects it before choosing another one. This prevents the wrong project or task from carrying over, reducing timesheet entry mistakes.
Original PR description
Steps to reproduce: ------------ - install timesheet_grid. - activate assistant. - select a suggestion and then unselect it. - select a different project suggestion. Issue: ----------- the project from the previous suggestion remains selected. cause: --------- currentRecord is not reset when a suggestion is unselected, so the previous suggestion's project and task are still reused. Fix: --------- reset currentRecord to null when the suggestion is unselected and showCreateForm is false. Effected pr-https://github.com/odoo/enterprise/pull/126450 task-6482312 Forward-Port-Of: odoo/enterprise#128374
A minor issue in the Sign app was corrected to prevent the system from trying to use a logging component that does not exist. This helps avoid unnecessary errors during document signing operations and improves reliability without changing user workflows.
Original PR description
See https://github.com/odoo/enterprise/pull/121960 Forward-Port-Of: odoo/enterprise#128748