Editable list was losing value when switching to other row from edited
cell (edit, tab-to-next-fiend then change record worked).
When changing row (by clicking on an other row or pressing up/down),
the list view simply request saving the current form and — once that
is done — switches the form to the new row.
The issue is in what happens *during* form-saving: for most text-based
fields (e.g. CharField-like) the field returns its internal
value. Said internal value was only synchronized when the internal
form control (input or textarea) fired the ``change`` event... and the
change event only fires *after blurring* (leaving) the current
field. So the form saving (and thus the retrieval of field values)
occured before the field could sync its internal value with the one
entered by the user.
Added a bunch of commit_value override to perform this synchronization
right before the field's value is requested.
Also removed an extraneous trailing comma in an array, and removed 2
useless temp storage (unused variables beyond their assignment).
bzr revid: xmo@openerp.com-20121210143808-wt4jmi4x0pg85xb8
I believe there are potential circular imports that can break
because of openerp.modules.module ImportHook, but they are
deifficult to reproduce when the import order is not always
the same.
bzr revid: vmt@openerp.com-20121210140411-ranw3jc3mwu3ymty
Server-side branch:
- needaction_enabled field on ir_ui_menu is now stored
- needaction_counter field on ir_ui_menu removed
- counters are accessible through get_needaction_data, called by the web client independently of the menu entries
bzr revid: tde@openerp.com-20121210131753-gtw4nyo5kosroq00
This web revision modifies the way needaction are loaded. Now they are loaded independently of the menus. After having loaded and displayed the various menus, a call to the server is done to avoid a long latency between the login and the display of menus. Needaction counter will be displayed as soon as they are available.
bzr revid: tde@openerp.com-20121210131658-pgy3t9t71f0z2yd5
these events are used by the autocompletion widget internally, if they
bubble upwards they also get handled by the list view which interprets
them as going up/down the list.
Prevent the latter by suppressing bubbling of these events.
bzr revid: xmo@openerp.com-20121210112203-3mry0pvecri0pv9o
Otherwise, if a search is performed while creating or editing a line
(e.g. in logged calls, create a line without saving then try to apply
a filter) the edition section (and new line) disappears but the list
remains in "edition" mode (e.g. save/discard button) even though
edition data is missing (trying to save or discard will error out).
bzr revid: xmo@openerp.com-20121210100914-delia5bhmtgrujpu
Nota: If we replace sequence signaling for cache invalidation with pg
listen/notify in the future, we will use the same mechanism for more accurate
cron timing.
bzr revid: al@openerp.com-20121209170447-zs0k3jazokylwvar
To tun the tests:
createdb t
/server/openerp-server --addons-path=addons,web/addons server -d t -i web_tests_demo
Once the server is ready, run, in an other shell:
/server/openerp-server --addons-path=addons,web/addons testjs
bzr revid: al@openerp.com-20121209024810-cdi2s9ftr97x8l5p
niv-openerp