Integer (and float) fields are actually well searchable.
If some integer fields aren't, it's because they hide functional fields.
In those field, the integer value is computed each time the values shows up in form fields.
You can't search through those values as they are not available in a computed form. Using the computing function when searching is not a good idea either as it may be CPU intensive.
fnct_search
A solution can be to assign a search dedicated function to the field. This may be intersting when you can return false positives, use an optimized method or you may search other data than the actual field. That function is setup using the "fnct_search
" parameter of field.function(). Unfortunately this is not always the best solution.
store
A second one is to ask the server to store the computed value. But in order to update the value when needed, you also need to know what will update it : which data change should trigger the field computation ?
Here the default is to recompute it when the object changed. Therefore you can use the "store=True
" parameter. But as it may not be accurate if your value depends of other objects, you may also use a 3-tuple like this one : (mapping_function,['trigger_field1','trigger_field2'],priority)
.
mapping_function
: returns the list of ids that needs to be recomputed
['trigger_field1','trigger_field2']
: fields that triggers computation when changed
priority
: allows ordering functional fields, useful to computed functional fields based on others
For this one, you need to take into account that it needs a database structure change when added on fields that don't have the store attribute, and that it may sometimes be difficult to predict which changes will trigger an update.
You may find more information about it in fields.py : bazaar.launchpad.net/~openerp/openobject-server/7.0/view/head:/openerp/osv/fields.py#L840
With that in mind, if you still think a field should be searchable (technically and practically), then a bug report is sure welcome.
You forgot to show your filter definition ;-(
I thought it was visible from the capture screen image.:) However it is a standard one "Quantity in stock superior or equal to 0" (zero). The result is not filtered at all! as products with zero or negative quantities are shown. I have tries tens of times always without success; I am using "V7 online"
Just tried it myself. Looks like a bug to me.
I made additionnal test of various advanced filters on the demo database (online); filters do not work on quantities (on hand or forecasted), nor on public price; they work on alphabetical values; they also work on cost (although numerical)! I wonder who will escalate the issue to the appropriate level to make professionnal testings and solve.
https://bugs.launchpad.net/openobject-library/+bug/1134329
When this will be solved? For v6 there was/is something like zero-stock-filter: http://v6apps.openerp.com/addon/7685?filter=%7B%22order_by%22%3A+%22downloads_sum+desc%22%2C+%22author%22%3A+391%7D&page=0
seems that the reported bug is not taken into consideration!
@Ad Libiton. Did you indicated that you are affected? Are you "Guenard"? Did "wjn" do so? Often, bugs only get attention in proportion to the number of complaints.
Yes I am Guenard! alias Ad Libitom
Yes, we have an Enterprise Contract and the OpenERP partner reported this bug to support@openerp as an issue for us.