in the search view documentation, they say :
Possible children elements of the search view are:
field
fields define domains or contexts with user-provided values. When
search domains are generated, field domains are composed with one
another and with filters using AND.
Fields can have the following attributes:
...
filter_domain
complete domain to use as the field’s search domain, can
use a self
variable to inject the provided value in the custom domain.
Can be used to generate significantly more flexible domains than
operator
alone (e.g. searches on multiple fields at once)
If both operator
and filter_domain
are provided, filter_domain
takes
precedence.
so for your example, with this as filter_domain
:
[
'|',
('product_variant_ids.name','ilike',self),
('product_variant_ids.attribute_value_ids.name','ilike',self)
]
if you search MEMORY
, it will be searched in one of the two given fields (by an ilike which is equivalent to sql's field ILIKE '%MEMORY%'
for your example).
product_variants_ids.name field
the searched value will be 'ilike'd with product_variants_ids.name
.
product_variants_ids
is a one2many to a list of product.product
.
the name
of a product is the name of his product.template
.
so this enable us to find product.template
by name (similar to ('name', 'ilike', self)
but will find only the product.template
with a variant).
product_variant_ids.attribute_value_ids.name field
product_variant_ids
is still a list of product.product
. attribute_value_ids
is a many2many to product.attribute.value
.
and the name of this product.attribute.value
is the attribute value, so in your given case 32gb
or red
.
Conclusion
So, this filter will not find MEMORY
or COLOR
, these are available in fields :
In a product view, you can search on tue attribute names (without change) like this :
- doing an
Advanced Search
,
- Choosing
Product Attributes
contains
memory
,
- Clicking on
Apply
.