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 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. > >>In addition, currently tryton not always show proof of a search. For > >>example, by the definition of search_name in parties (you can search a party > >>by his name or his code) > >Name and code are on the view. > > > >>and in invoices (you can search an invoice by its > >>number or its party), you can search an invoice in the invoice tree view by > >>the party code, and the results don't show proof of the search. > >The code of the party is show in the party column. > > No, test it! In the invoice tree view you can search by the code of a party, > but the party code is not shown anywhere (tryton v.3.2 and previous, I don't > know if it has been changed in trunk/3.4). It is an example and I think I > could find more like this. Great you find a misbehavior. > >>In conclusion, IMHO it is not essential show proof of the result of a search > >>in the tree view. And my experience show that it desirable that an ERP has a > >>powerful and flexible way to search data. > >I can not agree, my experience shows that if you don't provide clear > >information mistakes are made. > > > >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 ? 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“. Your design sucks. So you should come with a much better idea if you want me to look at it. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgp5iCqzkuRsS.pgp
Description: PGP signature
