Tuesday, April 2, 2024
4 changes · master
Enhancements to existing features
This update adds automated tests for an internal Point of Sale data model component and makes relationship tracking names more predictable. It helps reduce the risk of future regressions in POS data handling without changing the cashier-facing workflow.
Original PR description
Aside from introducing unit tests for the related_models module, we also changed the way missing back-references are represented. Before each missing back-reference name is generated using the…
Aside from introducing unit tests for the related_models module, we also changed
the way missing back-references are represented.
Before each missing back-reference name is generated using the following
template: `__dummy_${model}_${dummyNameId++}_${suffix}__`
Now, they're computed using: `<-${model}.${fieldName}`.
E.g.: given the following models:
```js
createRelatedModels({
"product.product": {
tag_ids: {
type: "many2many",
relation: "product.tag",
relation_table: "product_tag_product_product_rel",
},
},
"product.tag": {},
})
```
Each `product.tag` object will automatically be assigned a field called
`<-product.product.tag_ids` which points to the `product.product` objects
related to the `tag_ids`. Check the following test module for better
illustration: `models without backlinks > many2many relations`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA new internal capability lets Odoo quickly check whether matching records exist without loading or counting them. This improves clarity for developers and can make validation checks more efficient, with no direct change to everyday user workflows.
Original PR description
## Purpose It's often the case that it is necessary to check for the existence of records of a specific model that matches a domain predicate, usually done during python validation for enforcing…
## Purpose It's often the case that it is necessary to check for the existence of records of a specific model that matches a domain predicate, usually done during python validation for enforcing constraints. What is done currently is either a `search` with a `limit=1`, which is not optimal, as the `_order` is applied, in better case `search_count` is used instead. The issue is mostly a question of expressiveness, as `search_count(.. ., limit=1)` is not really obvious for what we are checking: existence. ## Feature Create a new model API endpoint `search_exists`, that takes a `domain` and check if there are records in the model that satisfy the domain. ## Implementation Check the existence with `SELECT EXISTS(...)` as it's the most trivial plan possible for what we are trying to do (InitPlan -> Results). Note that the presence of a limit, if it's not 0, will usually be optimized out by [postgres][1], so the presence of it on the query object is irrelevant. [1]:https://github.com/postgres/postgres/blob/0de5274f59c9d84d803d7f3dc75577d8aa6e56b8/src/backend/optimizer/plan/subselect.c#L1523-L1611 ## Reference task-3844634 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes outdated internal configuration fields from Odoo's payment setup screens and moves those settings directly into the relevant views. It helps keep payment provider configuration easier to maintain without changing day-to-day payment workflows for users.
Original PR description
[IMP] payment: Remove view configuration fields Post-"views-pocalypse", this commit eliminates obsolete view configuration fields in the payment module. Utilizes the <attribute add="..." separator="..."/> feature to seamlessly integrate settings like show_credentials_page, show_allow_tokenization, and others directly into views via XPath, removing the need for the _compute_view_configuration_fields method. task-3679393 See odoo/enterprise#56181 See odoo/upgrade#5667 See odoo/documentation#7686
The SEPA Direct Debit payment setup screens were updated to align with recent payment app changes. Configuration sections and message fields that are no longer managed this way are now hidden, reducing clutter and keeping the setup experience consistent.
Original PR description
Following the removal of explicit view configuration fields and the _compute_view_configuration_fields method in the payment module, this commit updates the payment_sepa_direct_debit module using xpaths to hide : - `credentials` page - `allow_tokenization` fields - `pre_msg` fields - `done_msg` fields - `cancel_msg` fields task-3679393 See odoo/odoo#152517 See odoo/upgrade#5667 See odoo/documentation#7686