diff options
| author | Xavier Morel <xmo@openerp.com> | 2011-10-06 08:39:49 +0200 |
|---|---|---|
| committer | Xavier Morel <xmo@openerp.com> | 2011-10-06 08:39:49 +0200 |
| commit | a3a45e18b3bf861de4f6b84892f2930dfb7c94b7 (patch) | |
| tree | ed9e8bb695c547d3d5dd4913ff277241ec0e3b7e /addons/web_graph/static/lib/dhtmlxGraph/codebase/dhtmlxchart_debug.js | |
| parent | aed28ba69b11af643b4f0aeee52788f69c720b25 (diff) | |
[FIX] m2o fields with selection widget in search view
Plan was originally to just ignore this because "it should just work"
but turns out m2o and m2o[@widget=selection] fields have very
different behaviors when it comes to default values, especially
custom domains and contexts:
* An m2o field uses its string value always (behaves like a char
field), for UI and clarity purposes we added an [[name, '=', id]]
case when the user specifically selects an autocompletion value,
but that's not "cannon", when it comes to dealing with custom
domains (filter_domain) and contexts the field always uses its
string value.
* An m2o[@widget=selection] field on the other hand uses its ids
always (behaves like a selection field).
That's not entirely true, really, because it has the converse to
what we implemented on the m2o field in the web client (in the GTK
client): if there is no @filter_domain *and* the user has entered a
value which is not in the dropdown (it's a combobox in the GTK
client), then it falls back on using 'ilike'. This string value is
*not* used in custom domains and custom filters, which simply are
not submitted.
This second section has *not* been implemented so far in the web
client, we'll come round to it if people actually need it.
bzr revid: xmo@openerp.com-20111006063949-fl5rbg3wwubcaay8
Diffstat (limited to 'addons/web_graph/static/lib/dhtmlxGraph/codebase/dhtmlxchart_debug.js')
0 files changed, 0 insertions, 0 deletions
