Added instance.web.ViewManager#get_view_id(view_type)
Fetch the title of the popup from the parent if it's a ViewManagerAction,
otherwise, use the current's view title.
bzr revid: fme@openerp.com-20130204124348-p79drjm72vt2j2ty
The "new" form engine performs a bunch of conversions on the form arch
from json to xml to text to json again (or something), thus the
``node`` attribute on form fields might be json but it's got no more
relation to the form's own arch (and the fields defined therein).
Meanwhile the domains processing for onchange recursively traversed
the *form*'s arch trying to find a node matching the key it had to set
its @domain to what it was given. It long predates the "new" form
engine, and since it alters the *original* arch not a copy the "new"
form engine broke it. And since that's untested, it's been broken for
a bunch of months (probably).
Fix by looking up the field according to the domain key (in
form.fields), and setting the domain in the node of the field, rather
than the node of the form's arch.
lp bug: https://launchpad.net/bugs/1088447 fixed
bzr revid: xmo@openerp.com-20130124144018-0g3sl2nej2aj6syp
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
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
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