jQuery's *focus* method must *not* be used: it triggers the blur and
focus events in the wrong order (and potentially more than once),
breaking the focus handling of the o2m editable list and making it
essentially unusable.
The DOM method behaves correctly, triggers the blur first and the
focus second in a different runloop frame (thus it's possible to bind
on blur, wait a set time and execute the actual blurring iif no focus
event has been seen within the form).
bzr revid: xmo@openerp.com-20121211145652-y63a0ny0gmoiozhn
when test is run right at the boundary between two seconds, after rounding to second generated date and reference date could differ.
check that generated date is within a small range (date created before and date created after) instead of equal to reference
bzr revid: xmo@openerp.com-20121210165006-y720xrwlo37sjwm8
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
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
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
Launchpad Translations on behalf of openerp