Friday, February 24, 2023
2 changes · master
Resolved issues and error corrections
This fix limits extra record-specific information sent when forms load related data. It makes form loading behavior more consistent and prepares the web client for a future streamlined data-loading approach.
Original PR description
The form view currently reads its data as follows: 1) read the main record, which returns [id1, id2...] for x2manys and [id, display_name] for many2ones. 2a) read x2manys records, with the context…
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be evaluated (some placeholder values need to be replaced by actual values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record as eval context. For 3, there an additional key "parent" in the eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a single rpc, returning the main record and its related records, with all the values required by the UI. To achieve that, we must ensure that sub records are never read with a dynamic context depending on the parent record.
This commit thus directly imposes the limitation, by removing from the eval context the record related data when it is used to evaluate the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
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-prWork order blocking reasons in Manufacturing can now appear in the user's selected language. This improves clarity for multilingual teams and helps shop floor users understand why work is blocked.
Original PR description
Blocking reasons on workorders are not translatable, this fixes that. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr