The big issue was the hooking on the closest ui-dialog's scroll event:
if an m2o in a dialog (e.g. wizard-type situations) toggled state from
editable to readonly (workflow action of some sort), the event hook
would remain, and call .$input.autocomplete("widget") which would blow
up because the autocompletion widget hasn't been re-initialized.
Take care to fully unbind all events during the reload process to
avoid this issue (and potentially other such as duplicate bindings and
the like).
lp bug: https://launchpad.net/bugs/1146321 fixed
bzr revid: xmo@openerp.com-20130306145527-sssv7ocfvqxgv896
m2m lists inherit (from listview/view) the handling of access rights
attributes (e.g. @create, @delete) in which the access rights to the
related model are those checked for the view. This is generally true,
but *not* for m2ms: even if a user has no creation rights to the
related model, he can still create a *relation* between the current
and related models.
The m2m access rights are really governed by the *current* (source)
model, in which case the user won't get to see an "editable" view of
the m2m in the first place.
So just override is_action_enabled to disable it in m2ms.
bzr revid: xmo@openerp.com-20130305091956-zn6qtuo4tl0vh3bs
* really call initial get_selection() after binding 'change:selection'
overwise no value are assigned to internal selection list - resulting
to an empty statusbar when field type is 'selection'
bzr revid: xal@openerp.com-20130304230253-0e959r9sintwsd98
jquery-ui's date picker (at least in currently used version) lets
*some* (but not all) clicks go through. The date picker dialog is
added directly to the page body so capturing clicks in a parent widget
doesn't work, and these "stray" bubbling clicks will trigger the
global bus's "click" event.
Add a capturing (and stopPropagation-ing) of these clicks in our
wrapper to jquery-ui's datepicker to avoid the issue.
lp bug: https://launchpad.net/bugs/1095283 fixed
bzr revid: xmo@openerp.com-20130225110614-p7dmmjd41xdxescy
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
Xavier Morel
niv-openerp
Xavier ALT
Fabien Meghazi
Christophe Matthieu
Vidhin Mehta
Thibault Delavallée
vta vta@openerp.com