On 01 Oct 09:09, Guillem Barba Domingo wrote: > El 01/10/2014 0:20, "Cédric Krier" <[email protected]> va escriure: > > On 30 Sep 21:32, Jordi Esteve (Zikzakmedia) wrote: > 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.
You are mixing ERP and BI like many of you. Tryton is an “ERP”, it manages business processes. > > > 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. Yes the only common known fields but personnaly I don't think we should have added it. I concede for you on this because there were no technical issue and it is only to help developers and they are not useful to users. > > > >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". OK, I will start talking again after you learn Tryton design. > 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). It seems that nobody is listening what I say. It was like that before and break things. The bookmarks will no more work. The behavior will be unpredictable. + all other comment I made in the thread. > > 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. So poor objective. This is not how to build a good software. Fixing something with something broken by design. > At the end, everything is a balance between the optimal solution and the > doa le and maibtanable solution. If you want but this exclude broken solution. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpGOzvRXAcT_.pgp
Description: PGP signature
