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
The main changes are:
- obsolete columns have been removed totally from ir.values (the meta* stuff, and the object column)
- existing columns have been documented, but preserved
- the set() and get() methods are deprecated, and internally delegate their tasks to the new set_action/get_actions and set_default/get_defaults.
- the API is now documented
- the administration UI for ir.values has been split in 2: defaults and action bindings now have their own menus and views
- added some new YAML (smoke-)tests.
bzr revid: vmt@openerp.com-20111003161404-s5wjo99q90oi435q
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
Yogesh (OpenERP)