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.