When dropping, would simultanously stop the edition and try a write
(so 2 writes on the same record) and generally screw up the state of
all the things, ending up with an empty row and a weird (and
incorrect) warning.
This can be fixed by preventing resequencing during the creation or
edition of a record (row) inline.
For simplicity, implemented by looking up .ui-sortable descendants —
there are no utility methods for handling that and, aside from the
class, there's no good way to know if sortability was enabled on a
list body or not (as far as I can see, jquery-ui's sortable has no API
to query that) — and using jquery-ui's sortable API for enabling and
disabling sortable on the fly.
lp bug: https://launchpad.net/bugs/1257753 fixed
bzr revid: xmo@openerp.com-20131210124755-ugr3ehf744qoh1o5
Tabbing is intercepted by keydown_TAB, which — if the current cell is
the last active field of the row — will then call _next:476. _next
then calls save_edition:300 which "takes a lock" (more precisely
serializes access to its body) and within its body checks if an
edition is active (:303) and returns immediately if not (:304).
The problem here is when a second tab event arrives during the
potentially extremely long save_edition body (since for toplevel lists
it needs to perform a complete RPC call): the overall state of the
list has not changed so the second event *also* goes into _next, then
into save_edition. There it's serialized with the ongoing call and
thus inactive until said ongoing call's termination, and reaches the
body after the current edition has been wound down. As a result, the
body of _next (:408) gets the resolution of ``$.when()``, which is
``null`` and the first condition blows up.
There are 3 possible ways to fix this:
* adding a check in keydown_TAB's handler to see whether a _next call
is ongoing. This requires adding a state flag to the object and does
not protect (or cooperate with) _next calls from outside this
specific handler, unless they are modified in turn.
* alter save_edition to *fail* in case there's no ongoing edition:
this part was originally in ensure_saved which does not care whether
a save was necessary or not and does not propagate save information,
so ``$.when()`` made sense. In save_edition, there are really 3
different outcomes: the save succeeded, the save failed (or
potentially part of save's postprocessing failed, for the current
implementation) and the save was unnecessary. But deferred only
provide 1 bit of state (success or failure), so the last state has
to be merged into either success or failure.
Both make sense, to an extent. Changing from one to the other (as
necessary here) could break existing code and have more extensive
effects than expected.
* the simplest and least far-raging change is to just alter the
save_edition().then handler to ignore cases where save_edition()
results in no saveinfo, this can be assumed to be a
bailed-out/unnecessary save call.
For simplicity, the 3rd solution was picked here although with more
extensive tests &al I'd have preferred trying out 2nd.
lp bug: https://launchpad.net/bugs/1253899 fixed
bzr revid: xmo@openerp.com-20131210093055-207fevqc1npy7fwr
JS objects are converted to py.object when passed in through the
evaluation context. py.object are not serializable by default (because
that doesn't really make sense), which breaks when the input is
intended as a dict and returned (e.g. o2m values, which are triples of
(int, int?, dict?)).
Intuitively, JS objects passed as part of the context should be mostly
JSON-ish and thus dicts, but that turns out not work work as some
addons use attribute accesses within contexts (e.g. parent.access in
account/account_invoice_view.xml)
=> Temporarily solve by converting raw js objects to an "attributed
dict" which acts as both a dict and an object and can be converted to
JSON.
Ideally, py.js should provide for a pluggable conversion, or should
use an attributed mapping internally. See issues 21 and 23.
lp bug: https://launchpad.net/bugs/1182101 fixed
bzr revid: xmo@openerp.com-20130624055929-3rtkgqrp4o87pvau
Following xmo@openerp.com-20130607120355-x3poxy2ar2bpqqvw:
* add_ids should not add ids which are already in the dataset, this
leads to duplicates which the web client does not overly like
* methods which add or remove records should not manipulate
dataset.ids as well as that's now automatic (on_write feature)
* record add should only insert the id in the dataset on non-false ids
(e.g. list edition uses "pending" record with false id during
creation, then sets the id it got from create() call)
bzr revid: xmo@openerp.com-20130607152326-2pja1kuwo0ropfuw
xmo