c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <708467@xxxxxxxxxxxxxxxxxx>]

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?

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/708467

Title:
  Act_window : Incomplete behavior

Status in OpenERP Server:
  Confirmed

Bug description:
  There has been a problem observed on act_windows(links or shortcuts).

  The problem is, act_windows do not respect domain and they work
  according to context set on search panel,but this context can lead to
  a completely wrong result.

  Example:
  Install stock module(With demo data).
  Go to Sales/Products , edit the code of CPU1 to be CPU.
  Click on Stock Moves(act_windows), you will see that the the purpose of link is not served at all. (result includes records for cpu2,cpu3) as well.

  
  Second problem, clicking NEW should set default product_id on new Stock.move,which doesn't happen anymore.

  Overall,
  1. If domain is not supposed to beset, there should be a special key which loads FILTERED records on links.
  2. 'default_FIELD':active_id or kind of relevant entry should appear in context.

  Thanks.