* 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
* DOM events sequence screwed up, requiring an explicit blur on the
current target to try and ensure the corresponding form widget would
register its own change event
* Requirement to stop the default behavior of keypress and keydown on
[Return] as they would somehow trigger the contextual menu of m2o
fields on the row, at the wrong place, when in a char field (I don't
even...)
* Delaying of the actual saving of the form (via `setTimeout`) to try
and ensure the blur/change event has had the time to propagate
correctly (and be handled) before we actually save
bzr revid: xmo@openerp.com-20120615055440-yn00uv4q8y29nboq
dataset.index was previously set to ``null`` in handler of [Create]
button (to fullfill contract with form view that dataset.index should
be ``null`` to indicate the creation of a new record with no id).
Issue: after setting the index to ``null``, the list view calls
``render_row_as_form`` which starts out trying to save a row being
edited (case: clicking of the [Create] button after having selected a
row for edition or after having written in a new record e.g. [Create]
-> type -> [Create] type -> ...). This tentative to save the existing
form would be performed in the context of a ``null`` dataset.index,
which the form view doesn't (and shouldn't, index should be that of
record *being edited*) expect.
-> first save in whatever dataset state is the current one, and *right
before* creating the new form (after having saved and/or discarded the
previous one) we have the id of the new record to edit (or ``null``),
find the index for *that* and set ``dataset.index`` to that (or
``null``) so the new form view can be created and opened in the right
context.
bzr revid: xmo@openerp.com-20120613153842-pd6xitjs8n003ogs
if the editable row's form isn't dirty, either nothing has been
entered in a new row or an existing row (being edited) has not been
altered, so can just discard the row (and reload it from cache if it's
an edition).
bzr revid: xmo@openerp.com-20120613153633-ms7i8t9lvdarxqi3
the user has not modified the editable line after opening it (whether to create a new record or to edit an existing one), so shouldn't be invalid
bzr revid: xmo@openerp.com-20120613153555-fq0moy1q464l92yj
- required fields may sometimes be provided by alternative columns,
and all the alternatives are therefore not required (e.g. for
a m2o the CSV can provide m2o or m2o/id columns)
- when fields share the same label, precedence when matching
column headers should be given to the field with the exact
same name, rather than just the first one encountered
bzr revid: odo@openerp.com-20120606174043-f1nmkad3p17mccyy
Don't prefilter via name_search if no data has been entered in the m2o
field, it's going to return all records (not paginated) so it's a
waste of time and resources
bzr revid: xmo@openerp.com-20120606124717-h2p211vbrydazado
* Some literal actions (not stored) provide an empty string for
domains and contexts instead of (respectively) an empty array or an
empty dict literal inside the string. Treat those case as nothing
being provided.
* Likewise some literal actions provide nonsensical (but falsy, but
not False) values for view_id (such as an empty list). Yield a
``False`` view_id for all falsy ``view_id`` received (``0`` should
not be a valid view_id, so ``False`` works)
bzr revid: xmo@openerp.com-20120606123508-ndh3jpzw1nabf98n
An optimization in the set() method of o2m fields
disables the direct computation of function fields
in order to avoid computing them line-by-line.
This is done with context key 'no_store_function',
and deferred at the end of the caller write() or
create() method.
This was unfortunately disabling all function fields
in parent model (via _inheritS) at the time of
creation, even though those were *not* batch-computed
at the end.
The patch removes the 'no_store_function' field in
the context that is passed to inheritS parents during
creation, as it was never meant to be passed.
lp bug: https://launchpad.net/bugs/704922 fixed
bzr revid: odo@openerp.com-20120604114536-4t6ulwl93zalfgr7
Xavier Morel