Friday, August 7, 2026
9 changes · 17.0
Enhancements to existing features
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
Original PR description
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
Resolved issues and error corrections
This update corrects how minimum insured salary information is recorded during Swiss payroll ELM transmissions. It helps ensure payroll transmission logs are complete and accurate for review and compliance purposes.
When stock is installed, the default routes of a warehouse include a rule that does Vendor -> Stock. However, once purchase is installed, that rule is removed and replaced by a 'buy' rule, that requires a vendor set on the product to trigger correctly. So when `test_orderpoint_activity_portal_context_leak` ran without purchase installed, it would find an applicable rule to run the orderpoint and would not trigger a ProcurementException, and thus no activity on the product. runbot-941316
Miscellaneous changes
## The problem When computing `pos_order_count`, the query starts from `pos_order_line` and aggregates all reward-related order lines before filtering on the requested loyalty programs. On databases with large PoS order volume, this causes millions of irrelevant rows to be processed. ## The solution Start from the lower-cardinality `loyalty_reward` table and filter the requested programs before joining `pos_order_line`. Merge the redundant second CTE into the first one and count the order I
Original PR description
## The problem When computing `pos_order_count`, the query starts from `pos_order_line` and aggregates all reward-related order lines before filtering on the requested loyalty programs. On databases…
## The problem When computing `pos_order_count`, the query starts from `pos_order_line` and aggregates all reward-related order lines before filtering on the requested loyalty programs. On databases with large PoS order volume, this causes millions of irrelevant rows to be processed. ## The solution Start from the lower-cardinality `loyalty_reward` table and filter the requested programs before joining `pos_order_line`. Merge the redundant second CTE into the first one and count the order IDs directly from `pos_order_line`, removing the unnecessary joins through foreign keys. ## Benchmarks Benchmark on a customer database containing approximately 7.4 million `pos_order_line` records: ||Time|Plan| |--|--|--| Before|5.5 s|https://explain.dalibo.com/plan/3e7978hg8f757614 After|1.6 s|https://explain.dalibo.com/plan/g588aa31e2bc6729 **Note:** An index on `pos_order_line(reward_id)` would improve this further. As discussed in odoo/odoo#167386, that index is added in master, while this query optimization targets stable versions where adding the index is not possible. **opw-6370166**
Original PR description
When stock is installed, the default routes of a warehouse include a rule that does Vendor -> Stock. However, once purchase is installed, that rule is removed and replaced by a 'buy' rule, that requires a vendor set on the product to trigger correctly. So when `test_orderpoint_activity_portal_context_leak` ran without purchase installed, it would find an applicable rule to run the orderpoint and would not trigger a ProcurementException, and thus no activity on the product. runbot-941316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
`test_orderpoint_activity_portal_context_leak` assumes that running the orderpoint will trigger a procurement exception. However, depending on which modules are installed (e.g., when `purchase_stock` is absent), standard stock rules for the test warehouse destination location can succeed in generating stock moves rather than raising an error. Deactivate all matching destination stock rules on the test warehouse prior to running procurement so the orderpoint is guaranteed to fail. runbot-94
Original PR description
`test_orderpoint_activity_portal_context_leak` assumes that running the orderpoint will trigger a procurement exception. However, depending on which modules are installed (e.g., when `purchase_stock` is absent), standard stock rules for the test warehouse destination location can succeed in generating stock moves rather than raising an error. Deactivate all matching destination stock rules on the test warehouse prior to running procurement so the orderpoint is guaranteed to fail. runbot-941316
When several xmlids point to the same record, PostgreSQL's UPDATE ... FROM can match multiple source rows to one target and pick an arbitrary value. Aggregate translations per res_id in import order so the later entry wins 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
Original PR description
When several xmlids point to the same record, PostgreSQL's UPDATE ... FROM can match multiple source rows to one target and pick an arbitrary value. Aggregate translations per res_id in import order so the later entry wins 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
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly [state](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L150-L155) , [amount_tax_signed](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L229) (e.g. `invisible=...`, `readonly=...`), the `modifiers` attribute is redundant and serves no purpose. This a
Original PR description
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly…
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly [state](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L150-L155) , [amount_tax_signed](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L229)
(e.g. `invisible=...`, `readonly=...`), the `modifiers` attribute is redundant and serves no purpose.
This attribute was never added manually by us — it was auto-generated by Odoo Studio when the default view was created. Studio's default views inject `modifiers` alongside the direct attributes. [Here](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-dfebe5a93e1b8880e88268b024be4c6f106d144b20298d7bb6c4ae09a18bafd0L67-L145)
Also the `modifiers` attribute was fully simplified [removed](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-849f1ed2a35a8b0b9cdd67f8e34de5d2ea7bf928103a83828587ba7ec14a62e4L52) starting from version 17.0, where views rely exclusively on direct attribute expressions (`invisible`, `readonly`, `required`) instead of the `modifiers` JSON encoding [main Patch](https://github.com/odoo/odoo/pull/104741) Keeping it around in the arch is therefore dead code with no effect.
However it needs to give the error on 17.0+ like this
```
ERROR LOG:
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_NOELEM: Expecting an element data, got nothing
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_INVALIDATTR: Invalid attribute modifiers for element field
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element tree has extra content: field
```
As the modifer has been remove from the field [common.rng](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-849f1ed2a35a8b0b9cdd67f8e34de5d2ea7bf928103a83828587ba7ec14a62e4L52) RelaxNG schema but modifiers set on fields here root tag is **form**, and the modifiers sit on fields inside a nested list. And Form views aren't RNG-validated from 17.0 till now —
[@validate('calendar', 'graph', 'pivot', 'search', 'list', 'activity')](https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/odoo/tools/view_validation.py#L314) has no form, and there's no [form_view.rng](https://github.com/odoo/odoo/tree/19.0/odoo/addons/base/rng).
Current senario
<img width="998" height="415" alt="image" src="https://github.com/user-attachments/assets/1a678c8f-8401-4e12-826f-9e98f6f2fe20" />
After removing the modifer: it show the same view because of field property
<img width="998" height="415" alt="image" src="https://github.com/user-attachments/assets/1a678c8f-8401-4e12-826f-9e98f6f2fe20" />
After removing the modifer still it shows the **modifiers="{'readonly':true, 'required':true}"** because the modifer is stay in the 14.0 but the 17.0 onwards it was not please see the scrrenshot its field preprty always.
<img width="1003" height="462" alt="image" src="https://github.com/user-attachments/assets/5e833924-b17c-417f-9e63-5a01c185f588" />
This Fix removes the unused `modifiers` attribute from the view arch, keeping only the direct attribute already present, with no functional change to the view's behavior.
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#279976On python 3.10.12 `test_export_translatable_resources` fails. This is fixed in this commit build-944659 I only tested it on 17.0 since we do not seem to have the build error on higher versions. But the minimum python version is 3.10 until [excluding saas-19.1](https://github.com/odoo/odoo/blob/11ee42b4bf70a1008b06d13a48263e42c381aeed/odoo/release.py#L39)
Original PR description
On python 3.10.12 `test_export_translatable_resources` fails. This is fixed in this commit build-944659 I only tested it on 17.0 since we do not seem to have the build error on higher versions. But the minimum python version is 3.10 until [excluding saas-19.1](https://github.com/odoo/odoo/blob/11ee42b4bf70a1008b06d13a48263e42c381aeed/odoo/release.py#L39)
Currently, people can get infinite loop in the cron that fetches messages from the ppf, as we don't catch the exception that may happen. First always catch them, so we don't prevent acking. Secondly, bypass the modification of the newly created message, even in case of audit trail. opw-6440955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Currently, people can get infinite loop in the cron that fetches messages from the ppf, as we don't catch the exception that may happen. First always catch them, so we don't prevent acking. Secondly, bypass the modification of the newly created message, even in case of audit trail. opw-6440955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr