On 01/10/14 09:09, Guillem Barba Domingo wrote:
El 01/10/2014 0:20, "Cédric Krier" <[email protected]
<mailto:[email protected]>> va escriure:
>
> You don't understand how mind works. Of course when checking if you did
> the right query, you don't redo manually the query but seeing a sample
> of the result very often give you an idea about the corectness of the
> query.
And you don't understand the customers/users... And a software is done
for them.
It's very common to sometimes need to search a record by a field which
is not very common to search by it => it doesn't make sense for
customer/user to ask a development to its provider (we, the
developers) to add this field because: a) he need it in that moment b)
maybe he don't need to search by this field anymore (but he'll need to
search by others non-common fields).
As this data is in its ERP (an information manageent system), it
produces FRUSTRATION.
As there isn't a good technical reason to don't allow this, but a
criteria of what is wrong or desirable in a search, I don't understant
why we can discuss to find the better interface to provide this feature.
Guillem has explained very well a common example that additional search
fields are needed in the normal use of an ERP. It is not a BI subject,
the user only wants to search specific records to manually update them,
for example.
For example, the search form could have a button ("extended search" or
"invisible fields") that shows the searchable fields that there isn't
in the tree view.
This second search view could have an "alert label" advertising the
user that these fields won't be shown in the list.
Yes, this could be a solution to advertising the user of using fields
not included in tree views.
> > And if the search field is not in the tree view but in the form
view, the
> > user can switch to form view and PgDown/PgUp to check several records.
>
> No, because it is the view of the sets that helps not one single record.
The ID, create/write date/user aren't in the tree viet but in the
search form.
> > >By the way, you did not give any hint on how to decide which fields
> > >should be included in the search by default. And if you answer all of
> > >them, it is completly wrong because there are fields that should
never
> > >be shown to users.
> > No, of course, all the fields should not been included by default.
I suggest
> > the visible and searchable tree and form fields for this user (add the
> > visible and searchable form fields to the current solution). Other
option
> > less user friendly will be define the search fields to include in
the code.
>
> This exactly what we had before and it was a disaster because of the
> unpredictability of the available fields.
> More over, there is not necessary a form view or there are many form
> view. And what about graph view ?
It's wrong. When you are in a tree view there is a form view
related... The view that will be used in the "swich view action".
I propose to add, in the "extended search form" all searchable (non
functional or functional with searcher) fields of all views related to
the current action (which will be used in swich view).
Yes, this is one of the my proposals, I think the better one for the
usability perspective, but Cedric says that it is not possible to
implement it without breaking things.
The other proposal is define the search fields to be included in the
code, but it doesn't solve the problem of immediacy and temporality that
Guillem has point out the user wants.
Other proposal is to add a boolean field in the ir.model.fields model to
check if the field is searchable or not. In a similar way that the
boolean "Global search" is used to check the ir.model is used or not in
the global searches. Then the fields shown in the filter would be the
current ones plus the ones with the searchable tag checked.
And if any good proposal can be found or implemented, the module
searching [1] that has started this discussion can be used to cover this
need, although it is not well integrated in the search filters of the
current tryton UI.
[1] https://bitbucket.org/zikzakmedia/trytond-searching
--
Jordi Esteve
Consultor Zikzakmedia SL
[email protected]
Mòbil 679 170 693
Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108
