Friday, August 28, 2026
8 changes · 17.0
Enhancements to existing features
This update speeds up internal database column lookups by using a more direct query instead of a slower generic system view. It can reduce time spent on these repeated checks during operations such as upgrades, helping improve backend performance without changing user-facing behavior.
Original PR description
Using the view `information_schema.columns` is slow compared to a simplified query using PG catalog tables. Here we propose to cherry pick the parts of the view that we actually use. Below we show…
Using the view `information_schema.columns` is slow compared to a simplified query using PG catalog tables. Here we propose to cherry pick the parts of the view that we actually use.
Below we show the timings of both queries as reported by the system on an upgrade 18->master with a runbot DB (many modules installed). All values are in milliseconds.
```
Original:
min: 0.931
max: 16.786
mean: 1.8790601284296555
sum: 25750.64
len: 13704
New:
min: 0.224
max: 11.832
mean: 0.8649024372446001
sum: 11852.623
len: 13704
```
Total time spent in queries was halved as seen in the `sum` statistic above.
Technically, the new queries are base on the original information schema view definition as returned by `\d+ information_schema.columns`. With all unused info removed.
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#216309The French PDP configuration no longer shows or uses the pilot phase option because the early participation period has ended. This simplifies setup for companies preparing for the standard French e-invoicing rollout and keeps workflows aligned with the current deadline status.
Original PR description
The pilot phase was there if people wanted to send before the deadline. The deadline has been reached, so we can remove the field from the view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures sales order lines recalculate remaining timesheet hours when related unit or availability information changes. It helps keep project and service delivery tracking accurate without requiring manual refreshes or corrections.
Original PR description
The dependencies of _compute_remaining_hours do not match the fields actually used for the computation: it lists analytic_line_ids, which it never uses, and omits both remaining_hours_available, and product_uom. _compute_remaining_hours_available has the same issue: it uses product_uom but only depends on product_id.service_policy. analytic_line_ids, on the other hand, can be dropped: qty_delivered already depends on it, along with its so_line, unit_amount, product_uom_id and project_id, so the timesheet flow keeps triggering the recomputation. This PR fixes the dependencies for both aforementioned compute methods. Task-4748521
Recurring preventive maintenance requests no longer create an extra reminder on the request that was just completed. This keeps reminders focused on the next scheduled maintenance item and avoids confusing duplicate tasks for responsible users.
Original PR description
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an…
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an activity is created for the responsible user. 3. Mark the activity as done. 4. Move the request to `Repaired`, or another done stage. 5. Check the newly generated request in the recurring series. When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series. The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`. Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request. The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request. Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request. opw-6409396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where static file paths could be split incorrectly on Windows after path normalization changed the separator format. The change helps ensure Odoo serves static resources reliably across operating 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 prevents an unexpected error from appearing when Odoo handles certain report actions. It improves reliability for users by ensuring the system uses the correct context when processing these reports.
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
Refreshing a Twitter/X feed no longer shows a generic error when an account token is invalid. Instead, the account can be disconnected as expected, reducing confusion and helping users recover access more smoothly.
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
Odoo Studio now only offers fields that are safely available when users build conditions for properties like readonly, required, or invisible. This prevents confusing errors caused by choosing fields that are limited to specific user groups.
Original PR description
Before this commit, when creating a condition for a field property in studio (like readonly, required or invisible), the fields available for the construction of the condition expression, were all the fields in the arch of the view. So, if you were using a field that was inside of a node with a 'groups' attribute or that the field had a 'groups' attribute, then a notification error was shown but with no real explanation on the cause of the error. After this commit, the fields availables in the construction of the conditional expression, are the fields in arch without any 'groups' attribute or any parent node with a 'groups' attributes. Help Task ID: 3660703