Friday, March 24, 2023
3 changes · master
Code cleanup and technical improvements
This change improves how Odoo handles screens where the same field appears multiple times with different rules or filters. Each field instance can now use its own settings, reducing incorrect behavior in forms and lists across several apps.
Original PR description
Before this commit, the use of multiple <field> with the same name in a view was not well supported. Why was this? Some Field components need to know information related to the <field> such as…
Before this commit, the use of multiple <field> with the same name in a view was not well supported. Why was this? Some Field components need to know information related to the <field> such as context, domain, required and readonly. The solution used before this commit to access this information is to use the getFieldContext, getFieldDomain, isReadonly, isRequired functions of the model. Unfortunately, these only take into account the last occurrence of the <field> because the model is not aware that the same field is present several times on the view. The information must therefore not come from the model. For example, it was not possible to have the same field twice with 2 different domains. It will use the domain of the last field for both. Solution: We will add the object "dynamicInfo" to the fieldInfo passed to the Fields extractProps function. This object will contain a getter to get the value of required, readonly, domain and context for the current <field>. If a Field needs one of its information, it will just have to get it from extractProps. Part of Task: 3179751
The Point of Sale barcode scanning logic has been reorganized to make it easier to maintain and more consistent across related POS features. Stores can now still open the POS even when barcode configuration is missing, with a clear error shown when scanning is attempted.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change improves how Odoo handles screens that show the same field more than once with different rules. Each field instance can now use its own settings, reducing incorrect behavior in forms and related views.
Original PR description
Before this commit, the use of multiple <field> with the same name in a view was not well supported. Why was this? Some Field components need to know information related to the <field> such as…
Before this commit, the use of multiple <field> with the same name in a view was not well supported. Why was this? Some Field components need to know information related to the <field> such as context, domain, required and readonly. The solution used before this commit to access this information is to use the getFieldContext, getFieldDomain, isReadonly, isRequired functions of the model. Unfortunately, these only take into account the last occurrence of the <field> because the model is not aware that the same field is present several times on the view. The information must therefore not come from the model. For example, it was not possible to have the same field twice with 2 different domains. It will use the domain of the last field for both. Solution: We will add the object "dynamicInfo" to the fieldInfo passed to the Fields extractProps function. This object will contain a getter to get the value of required, readonly, domain and context for the current <field>. If a Field needs one of its information, it will just have to get it from extractProps. Part of Task: 3179751