| Thread Previous • Date Previous • Date Next • Thread Next |
Hello,
This is an interesting suggestion, but the reality is much more complicated, unfortunately.
There are two mains reasons for that:
1.- Not many function fields can have a proper fnct_search method. In many cases, the only way to implement it would be to compute the value of the function field for all database records, and then search among these for a match. This is not only very inefficient, but also dangerous in terms of performance, and cannot be allowed. On top of it, this approach requires implementing many search operators (like, ilike, =, !=, >, <) in pure python (for searching among the computed results in memory) which would be stupid: the database is the right place for this.
So it only makes sense to implement the fnct_search when this search operation can be translated into a very efficient postgresql query. This is the case for the "Available quantity" of production lots, because you can make an efficient query on the only stock moves that are related to this specific production lots, presumably not many, and the compute their balance.
It is typically _not_ the case for the "Quantity on Hand" field of products, because you would need to compute that value for _all_ products in the database, and only afterwards match the desired filter.
And as you would like a button on the search view for "Quantity on Hand > 0", imagine the disaster!
2.- For the reason exposed in 1.- about operator implementation, the few
fnct_search implementations we have only support very few operators, and
not very complex domains. So you get a very partial support for
searching on function fields this way.
Because of the above, let me suggest a different approach: the community can suggest minimalist implementations of fnct_search using merge proposals. If the implementation is efficient and correct (or can be made so), we'll help to get that merged into the official branches.
And of course, if this is something you cannot live without, you could always make a custom module that adds the desired fnct_search - but that would be too dangerous in the core :-)
PS: By the way I've explained many times that the search on function fields that was available in 5.0 was totally broken and misleading ;-) It only worked on the records currently visible in the client. This was by nature wrong, and even worse: most people were not aware of it! Please do not call that a "lost feature", it was never there ;-) To use your example: if you were filtering/sorting on the "Product/Stock on hand" you would only do that on the 80 products visible by default - useless and wrong....
Instead of having a (silently) wrong and misleading feature, it's clearly better to remove it. As you can understand with the above explanation, making this feature really work is not just a matter of throwing in a few easy fnct_search implementations!
** Changed in: openobject-addons
Status: New => Won't Fix
--
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to OpenERP Project Group.
https://bugs.launchpad.net/bugs/850752
Title:
fnct_search missing for many function fields
Status in OpenERP Addons (modules):
Won't Fix
Bug description:
according to
https://bugs.launchpad.net/bugs/823049
it will be possible to search for function fields store = false if fnct_search is defined
a quick search shows
280 function fields in addons
14 fnct_search
it would enhance the user experience a lot if at least for the most important function a searech could be defined for 6.1
as it is the rebirth of a lost feature available in v5 it would also easy migration.
will you implement search functions if we / the community nominates some important candidates ?
like
* product stock available / on hand
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/850752/+subscriptions
| Thread Previous • Date Previous • Date Next • Thread Next |
