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
this means if the auto_search attribute is missing, search automatically. Search should only
be prevented if auto_search is precisely false
bzr revid: xmo@openerp.com-20111005111210-qju8ocbhvqahczsz
The static homepage do not reload the page when the module installed have no configuration actions (eg: returning direcly ir_actions_act_window_close)
bzr revid: fme@openerp.com-20111005101714-s5jy3gslni00a5jo
Form fields are extended/replaced in editable list view in order to
handle @invisible and @tree_invisible correctly in editable-list-form
context (base semantics of @invisible are different between listview
and formview, formview's @invisible is listview's @tree_invisible, and
instead of removing element from visible DOM listview's @invisible
only hides the element but it keeps the space it's taking).
As a result, listview editable needs to override Widget.update_dom for
pretty much all form widgets, in order to manage this difference in
behavior.
In case of @tree_invisible, it did so correctly setting and unsetting
its stuff and calling this.super() to execute the widget's actual
update_dom triggers **but it did not do so when the element was really
visible**.
As a result, in editable listview elements would never appear required
(blue background), invalid (red background) or disabled (gray),
although they were correctly set up, because the display layer was
never updated.
bzr revid: xmo@openerp.com-20111004151031-65o0q8e86op7kdks
I don't remember why I did that originally, it does not seem to serve any purpose and it causes problems in case of records with binary fields
bzr revid: xmo@openerp.com-20111004102115-lz6kgyiw35vp1t99
Session#session_restore is automatically called when the client
session is started, and it performs an RPC call. This RPC call is
checked and leads to the opening of the login form iif the user is not
currently logged in (does not have a valid session).
Due to the behavior of Session#rpc_ajax, this failure on grounds of
invalid session leads to the restore continuation being stored for
deferred execution once the user logs in.
Issue is that both Session#session_login and Session#session_restore
call Session#on_session_valid which tries to load all modules. As a
result and because the '_modules_loaded' flag is only set five billion
years after 'load_modules' is called both calls will try to load all
modules in parallel, leading to double downloading and execution of
all JS and CSS files coming from module data (including translation
files).
bzr revid: xmo@openerp.com-20111003090709-ree0luomezw1wzup
Session#session_restore is automatically called when the client
session is started, and it performs an RPC call. This RPC call is
checked and leads to the opening of the login form iif the user is not
currently logged in (does not have a valid session).
Due to the behavior of Session#rpc_ajax, this failure on grounds of
invalid session leads to the restore continuation being stored for
deferred execution once the user logs in.
Issue is that both Session#session_login and Session#session_restore
call Session#on_session_valid which tries to load all modules. As a
result and because the '_modules_loaded' flag is only set five billion
years after 'load_modules' is called both calls will try to load all
modules in parallel, leading to double downloading and execution of
all JS and CSS files coming from module data (including translation
files).
bzr revid: xmo@openerp.com-20111003090709-1izso4hrbzk91sf3
niv-openerp