Act_window : Incomplete behavior

With the priority set to medium, assigning it to Framework as it would include all the teams to work for the solution(s).
Thanks.

Hello Sir,

The fix for addons has been committed to lp:~openerp-dev/openobject-addons/trunk-dev-addons1-extra with revision number 4684.

Soon it will be merged into main addons.

Thanks.

If I understand correctly you are referring to the fact that using default_search_* in the context does not give the same behavior as the "domain" we used to set on <act_window>s, providing behavior 1. and 2. you quote above.
First, remember that using search_default_* is much better as it makes the "domain" explicit, the user knows at all times that this view is filtered, and how, and can also remove the filtering manually.

Now, let's consider each separate issue, in random order..

Behavior 2 (defaults for new records):
In many cases we don't care, these links are meant mostly for read-only access, and not much for creating new objects. Your example is typically one case where we don't actually want the product_id to be forced when we create a new stock move.
Now there are cases where we care (e.g. Project -> Tasks, as this is a handy way to create tasks), and in these cases using the "default_*" context trick in addition to the search_default_* is a much better solution than a forced "domain", as the value is only a suggested default, but can still be modified. The "domain" behavior was seen by many people as counter-intuitive, hidden, and sometimes they would think they were facing a bug that prevented normal selection of values.
So basically I think this behavior glitch is a minor issue, and the branch proposed by Ujjvala solves it for most cases. And even if we don't really need it everywhere (like your example), it doesn't really hurt as it's only a default, not forced.

Behavior 1 (list filtering using exact match):
As for behavior 1., it is more annoying as it impacts also "read-only" browsing, and there is no clean solution using our frozen 6.0 API, short of modifying both clients. But it seems that this should be limited to m2o fields defaults, so perhaps the m2o widget for search views could have a workaround and be able to distinguish 2 cases:
- its value (an ID) was set via 'search_default*' in context, and it translates to this domain: [('field_id', '=', id_value)]
- its value (a string) was entered in the field, so it translates to this domain: [('field_id', 'ilike', string_value)]
This would mean that the [('product_id', 'ilike', 'CPU')] would instead become [('product_id', '=', 2)] and solve the issue.

What do you think?

Note: the proposed branch has not been merged to the point of the fix relevant for this bug, this appears so only because on already-merged branch was reused to implement this fix.

@Ujjvala: please remember to use feature branches when doing bugfixes of this scale, to avoid such issues, thanks!

sorry: i do not understand this point of view:
Just be a user, standing in the products (you are selling). You have a product named RA and a part named RAA. Now you have a problem with your stock of product RA. switching to stock moves (coming from the product), you now see all stock moves from part RA, but also from product RAA? Does this make sense? In version 5 the behaviour made sense, because you saw only stock moves from product RA ....
Using operators is mighty, but a programmer should use those operators, which make sense to the user....

it would be better to set the standard operator to equal and let the user decide if he wants to use "like" ...
user should decide! always .... life should become e a s i e r using software ...

and ....
in which way is the user in this example able to see the stock moves of product RA? no possibility...

Hi Olivier!

Trying to think as a user (and I think, I can say I’ll manage that quiet well) let me describe my point of view.

Could be, that it depends on the data that need to be filtered, but (keeping the excample ‘product’) entering a unique product – sorry, another bug ;-) – in ANY tree filter lets me expect to get a list with information JUST for this product. Why should I use a more detailed filter when I already know what I am looking for?

If I am looking for kind of information like ‘list all move lines of products beginning with ‘RA’ (because ‘RA’ qualifies a group of products)’ I won’t mind using a ‘like’ search (either through ‘%’ or special filter which sets the like function).

And to be honest: I do not understand why you gave up the philosophy you followed in version 5 – this issue is an issue in V6, right?

Am I wrong?

Steffi

Hello Guys,

Everyone of you are trying your best way out to represent your desired way to work. You all are right.

My aim of posting this was to mention that the feature we presented has something missing in its original approach.
My view says that, we clicked on shortcuts(which lead us to SPECIFIC set of records),so we should see absolutely specific records.

1. Default for new records:
-- I disagree with Olivier (This is really rare,inconvenient to write this) that this is negligible. We actually have to care I believe.
I am not sure that all the records (generated by the click on act_windows) would be readonly always. Lets think as an administrator who doesn't really like to bother to do more clicks.
-- 'default_*' is the best preferable solution here as very well initiated by Ujjvala. Thanks Ujjvala.
-- I guess, we all agree to this point.

2. Filtered records on click of act_windows:
-- @Steffi, 'HARD DOMAIN' was a workaround for 5.0 series and 6.0 comes with a great turn with search panel which lets you clear all the conditions and make a new filter as per your need. In 5.0, what happens is the resulting windows do not let you create a new search and thus puts you in a restricted area of choosing something very limited.
-- I am not in favour of domain like [('field','=',active_id)] which will again put some restrictions and user would feel being in jail.
-- Let us just don't talk about specific example.
-- Steffi talks in functional aspect and Olivier talks very accurately in order to put framework and Changes on safer stand.
-- However,I can suggest a solution where we can think of these alternate solutions:
A. Introduce a key on context like {'context_domain':[(''field","=",active_id)]},so that while the act_window gets loaded first time,this domain is applied ORed with normal condition(as what happens currently) on search panel.(name_get one).
B. When act_window click is triggered, Clients should interpret as [('field','=',active_id)] only for the first time. As soon as the clear is clicked, domain and context should be set to [] and {} (as it happens currently).

Note : Setting name_get() on search panel seems a little uncomfortable as it will disturb the result. If this is true, name_search() should always be treated in parallel to generate the accurate results on search. Look at the bug 708593, which I think,should be fixed on addons taking this discussion into consideration.

Thanks.

Hi Jay!

before I will answer your post above: the patch you sent me - what will it change/how does it work? I won't mind waiting to install it as long as we still discuss about a 'final' solution...

thanks

PS: the patch you sent us on ticket 3813

Hello Stefanie,

As I mentioned,the patch I sent to you is just a temporary workaround for you,which adds a domain to your act_window.
It cannot be treated as a final solution.

Let us know if things are not clear.

Thanks.

@Steffi and Michael:
As I understand that you expect the search fields to perform "Exact match" of values instead of "like" match by default, and only do "wildcard matches" only when you ask the system to do it.
However this is not the default behavior of OpenERP for many reasons, and this has not changed in v6, there is not "philosophical" difference. It may appear to you that it changed, but this is only because of other changes related to search views and the way "related links" are followed. If you do a normal search on the product name in the regular products list, you will see that the search/match behavior is identical in v5 and v6.
One of the reasons for this default is that it is much more frequent for users to search for a non-exact match than an exact match (think of Google), and I don't think we are going to change this anytime soon. We could however provide a more user-friendly mechanism for searching exact matches, like quoting the terms, etc.

Incidentally, OpenERP allows you to customize your views and assign the "=" operator to your search view fields if you like, but the default is the fuzzy operator "ilike".

Now, as this is a much vaster topic and definitely not a bug, please let's concentrate on the issue at hand: exact match searches when following related links in side-bar. I'll do that in a separate comment.

To summarize the 2 parts of the current view:

1. Default for new records:
This is settled by the proposed branch from Ujjvala, which we'll review and merge.

2. Filtered records on click of act_windows:
Jay, I can't agree with your suggestion to add a "context_domain" for this purpose. Firstly because 6.0 is out and such API changes are against the policy on a stable branch, secondly, because it would add yet another weird context parameter, making the API and XML even more complex, and finally, because it would mean that the same info is added yet another time to the context in a different syntax.. i.e. more duplication of code (search_default + default_ + context_domain?).
So let's pick option B, which is the same as what I proposed (yes when you clear the search the default coming from the related link is dropped too). We can thus discuss this implementation on both GTK and Web Client.

As a summary for the R&D teams, this means we modify the clients to handle the search_default_xxx values on many2one fields as exact matches using the ID (e.g. adding to the domain something like [('field_id','=',id)], and revert to the default behavior [('field_id','ilike','value')] as soon as a manual value is entered or the search view is cleared.

Alright, we can opt for Solution B.
Thanks.

Confirming for GTK client and Web client, to implement the chosen solution:

=> When a default value is provided for a m2o search field via a context default, eg:
        context = "{ 'search_default_product_id' : active_id }
=> ... Then the filtering that is applied by the client when the search view is submitted must be using the numeric ID and the "equal" (=) operator. (i.e an exact match)
=> When the value of the m2o search field is manually changed by the user:
=> ... Then the filtering that is applied by the client when the search view is submitted should be using again the default operator for that field (comes from "operator" attribute, and by default is "ilike").

Thanks!

Bug is already in progress with addons, as a merge proposal has been submitted, and is ready for review.

hello

Thanks for the report !

It has been improved in gtk at lp:~openerp-dev/openobject-client/trunk-dev-client with revision-info 1455 <email address hidden> and will be merged soon to the trunk client.

Thanks

Hello,

Its fixed in trunk web-client. Please update your code.

Revision-info:
4499 <email address hidden>

Thank you for notifying.

Hello,

It has been improved in addons at lp:~openerp-dev/openobject-addons/trunk-dev-addons1-act_window and will be merged soon to the trunk addons.

Thanks