this way, we can consistently display m2m tags anywhere without dummy CSS copy/paste (example: projet issues, projet tasks)
oe_form_field_many2manytags became oe_field_many2many_tags (container)
oe_form_field_many2manytags_box became oe_field_many2many_tag (item)
Qweb templates names have been changed accordingly
bzr revid: abo@openerp.com-20120712125637-hji6e9chch1h01f0
After opening a record with a list o2m, editing said list o2m and
saving a row, clicking the action button would lose all data
explicitly changed: the o2m would just call the action without saving
the form's current state, so the corresponding server method would
only be able to use data previously saved.
Fixed by overriding do_button_action, and only calling the _super()
method after the parent form has announced it is saved (either because
nothing was changed or because it did indeed save itself).
bzr revid: xmo@openerp.com-20120622085432-mh3977uygua5bypn
* Throw out focusin/focusout: the m2o widget's completion list is
created at the page top (body) so the editable listview can't
generically handle arbitrary widgets via mere focusin/focusout.
* Move responsibility of focus/blur events to the form view and its
widgets.
* Events could not just be named ``focus`` and ``blur`` due to usage
of jquery's event system: jquery will automatically call a method of
the event's name if it exists on the object, which conflicts with
.web.form.Field#focus and leads to an infinite loop (as Field#focus
focuses the field's root element, which triggers the focus event,
which calls the focus method,...) => form-* and widget-*, can be
switched back in trunk
* m2o mess kind-of complex, basically:
- the core input and the menu button behave as blur/focus triggers
- when the autocompletion list is clicked, it will temporarily
remove the focus from the input (blurring it), and put it back
later... on a timer. Issue is the timer, we don't want to rely on
having a bigger timer (as later revisions of the library may
change our timings and it's iffy to rely on timers conserving
order perfectly); on the other hand we know the focus *will* come
back to the input eventually. So we can just avoid propagating
blur iif the blur is the consequence of having clicked on the
completion list.
- roughly the same thing happens when clicking on $drop_down (after
fixing the handling of its final focus to be consistent, as
$drop_down would not re-focus the input if it was *closing* the
completion list)
- pretty sure the menu thing does *not work at all*, but I don't
have the courage of fixing it before committing this part.
Date/datetime widget remains to be handled, basically the core focus
handling is the same as in e.g. a charfield *but* needs to handle (and
ignore) loss of focus from clicking inside the picker
widget. Expecting the level of suck to reach unknown heights.
bzr revid: xmo@openerp.com-20120619072518-lsrhzij5asxt2aea