In #5853 (closed) patch we're unconditionally sorting the M2O according to the proximity field.
Not only is this behavior not efficient in all the other cases, this kind of specific order when searching on a relation is a generic feature that is useful elsewhere.
Thus adding a keyword order_search on the relational fields defining the order used when searching would be a nice addition.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Indeed why aren't why implementing search_context and search_domain also?
The first can be used for sale_ and purchase modules to show product quantities when searching products, but not setting the context when browsing the records on server side.
The latter can be used to restrict the results of a select, for example only allow to select validated customers on sale without forcing a domain because the party can go to invalid after the sale have been encodeed.
* Sergi Almacellas Abellana [2016-11-30 16:37 +0100]:
>
>Sergi Almacellas Abellana <sergi@koolpi.com> added the comment:
>
>Indeed why aren't why implementing search_context and search_domain
>also?
>
>The first can be used for sale_ and purchase modules to show product
>quantities when searching products, but not setting the context when
>browsing the records on server side.
>
>The latter can be used to restrict the results of a select, for
>example only allow to select validated customers on sale without
>forcing a domain because the party can go to invalid after the sale
>have been encodeed.
OK let's do it too then.
According to me those two additional attributes should be merged with
their equivalent non search related attributes. For the domain, it's
easy: just AND them.
But for the context, it's a bit tricky which one should have the
priority. According to me the most local one (ie: search_context)
should have the priority.
I have a concern about the search_domain as it is implemented because it could generate a constraint when creating new record form the search window. I think it is wrong to force value base on the search_domain because it should not be a constraint. Also about the UX, we could have weird behaviour like user clear the value of a Many2One but he can not add it back. So I think the search_domain should only be a default search filter.
>I have a concern about the search_domain as it is implemented because
>it could generate a constraint when creating new record form the search
>window. I think it is wrong to force value base on the search_domain
>because it should not be a constraint. Also about the UX, we could have
>weird behaviour like user clear the value of a Many2One but he can not
>add it back. So I think the search_domain should only be a default
>search filter.
Those are valid concerns and I implemented search_domain as a default
search filter by using the search_value attribute of the screen.
It works but the issue I have with it is that if the user does not
leave the field empty when making a search then the search_domain is not
used at all. But on the other hand this behavior is coherent with the
one used when updating the autocompletion, so it seems alright.
With my last comment [1] on the review, I think search_domain is a bad idea.
I think the same behaviour can be achieved using a PYSON domain based on the id of the record or the state. We already have an example in sale_shipment_cost module for the field Sale.carrier.
So for me, we should drop the search_domain as it is a duplicate feature of the actual domain.