Allow searching on all fields by default

Currently only fields in the tree view are searchable but latest Tryton version allows the user to search on any field of the model related in a Many2One field.

For example, in the Invoice tree view I can search for invoices with Party.Accounts: 43000 but I cannot do the same search (using “Accounts: 43000”) in the parties tree view.

That looks quite inconsistent to me.

Maybe fields in the tree view should be the only ones shown in the search popup dialog, but all fields should be available in the search bar with auto-completion.

Thoughts?

Indeed I think we should limit the relation fields to the one defined on the target tree view (defined on the view or the default one) and not the opposite. It does not help the user to throw all fields without consideration.

Personnally, I would like to be able to filter on any field, and not only the one in the view. It permits greater flexibility on what can be done with standard interface.

For now, when I need to retrieve specific elements, I am using proteus. And for editing a set of records, it is a pain. For me, it is raising the bar too much even for advanced user.

But I can understand that autocompletion for all fields could be disappointing for a new user.

Maybe the autocompletion should be only for used fields in the view, but permit using all fields in search ?

+1 allow search fields that are not in tree view.

Users like to search records that fields are not in tree view. Also, a dev is boring task to inherit views to add fields that users like to search (custom view).

Since 3.8 I have a patch in GTK client that allow search in tree view all fields that are in form view:

diff -r 92b092f49a28 -r 291cbda7e4c0 tryton/gui/window/view_form/screen/screen.py
--- a/tryton/gui/window/view_form/screen/screen.py	Thu Jun 11 15:37:30 2015 +0200
+++ b/tryton/gui/window/view_form/screen/screen.py	Thu Nov 26 16:17:34 2015 +0100
@@ -107,6 +107,13 @@
 
     @property
     def domain_parser(self):
+        def extract_nodes(node):
+            l = []
+            for node in node.childNodes:
+                l.append(node)
+                l.extend(extract_nodes(node))
+            return l
+
         view_id = self.current_view.view_id if self.current_view else None
 
         if view_id in self._domain_parser:
@@ -124,7 +131,16 @@
         else:
             view_tree = self.fields_view_tree[view_id]
 
+        try:
+            view_form = RPCExecute(
+                'model', self.model_name, 'fields_view_get', False, 'form',
+                context=self.context)
+        except RPCException:
+            view_form = None
+
         fields = copy.deepcopy(view_tree['fields'])
+        if view_form:
+            fields.update(copy.deepcopy(view_form['fields']))
         for name, props in fields.iteritems():
             if props['type'] not in ('selection', 'reference'):
                 continue
@@ -139,8 +155,15 @@
             xml_fields = [node_attributes(node).get('name')
                 for node in root_node.childNodes
                 if node.nodeName == 'field']
-            fields = collections.OrderedDict(
-                (name, fields[name]) for name in xml_fields)
+            if view_form:
+                xml_dom = xml.dom.minidom.parseString(
+                    view_form['arch'])
+                root_node, = xml_dom.childNodes
+                xml_fields += [node_attributes(node).get('name')
+                    for node in extract_nodes(root_node)
+                if node.nodeName == 'field']
+            fields = collections.OrderedDict((name, fields[name])
+                for name in xml_fields if fields[name]['searchable'])
 
         # Add common fields
         for name, string, type_ in (

I personally don’t see such a problem with autocompletion, that’s why I proposed to hide those fields in the search dialog. After all, the search dialog is already a tool for not so advanced users and does not allow searching on records that are different from a given string, does not allow to search on relate fields, etc.

For me, the most annoying part of not being able to search on all fields is when they have a need for searching on a field they don’t usually need to and you’ve got no alternative. I usually propose to export records to Excel and apply a filter there, but that’s not very appropriate IMO, specially given how powerful is the search Tryton already provides.

I’ve had some feedback from some users that they expect the same behaviour. I’ve been told that “Advanced searching is not possible with Tryton”. Normally this feedback is from users that already familiar with Tryton, not for newcomers.

Altought I agree that allowing to search on all fields will be a good feature I’m a little bit worried about adding so much fields will confuse new tryton users.

So this sounds like a good behaviour to allow searching on all fields but keep it simple for new users.