El 01/10/2014 0:20, "Cédric Krier" <[email protected]> va escriure:
>
> On 30 Sep 21:32, Jordi Esteve (Zikzakmedia) wrote:
> > El 30/09/14 a les 17:30, Cédric Krier ha escrit:
> > >On 30 Sep 17:02, Jordi Esteve (Zikzakmedia) wrote:
> > >>El 26/09/14 a les 19:35, Cédric Krier ha escrit:
> > >>>On 26 Sep 18:41, Jordi Esteve wrote:
> > >>>>On 26/09/14 18:08, Albert Cervera i Areny wrote:
> > >>>>>2014-09-26 17:59 GMT+02:00 M. Murray <[email protected]>:
> > >>>>>>Hello Everyone,
> > >>>>>>
> > >>>>>>I have a question regarding the search query builder in the tree
view. It is
> > >>>>>>the window that pops up when you click the "Filters" button/label
at top
> > >>>>>>left.
> > >>>>>>
> > >>>>>>How can I modify the list of fields that shows in that popup?
> > >>>>>Just change the tree view. You can search on all the fields of the
> > >>>>>view except those that are not searchable (usually calculated
fields)
> > >>>>>and the client also adds some special fields such as id, create and
> > >>>>>write date and users.
> > >>>>>
> > >>>>>Note that you can add fields to the view but make them "invisible"
so
> > >>>>>they're searchable but are not shown to the user.
> > >>>>Adding filter fields with a more flexible way than changing the
tree view
> > >>>>would be a nice feature for Tryton. In my experience, the user
wants to
> > >>>>search by a lot of criteria, no only by the fields showed in the
tree view.
> > >>>>This requirement is very common in party and product views.
> > >>>>
> > >>>>I don't know if other people has this need and if it would be very
difficult
> > >>>>to implement in the core of Tryton.
> > >>>I'm strongly against, it is a wrong user experience to not show
proof of
> > >>>the result of a search.
> > >>IMHO it is not essential show proof of the result of a search in the
tree
> > >>view. The users are -normally- intelligent enough to change to form
view and
> > >>check the search criteria is met.
> > >And how do you check for thousand records?
> > >Sorry but when I do a SQL query for example, I always select columns
> > >that I use in the where clause to be sure to not make mistake. Human
> > >makes mistake and we should do our best to help them to fix them.
> >
> > If the search returns thousand records, the user either won't check all
the
> > records in tree view.
>
> 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 os 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.
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.
> > 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).
> And it doesn't fix at all the initial claim which was “it is not
> possible to know which field user want to search on“.
It improve the current situation, which is too much limited in our
experience.
At the end, everything is a balance between the optimal solution and the
doa le and maibtanable solution.
Guillem Barba
