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
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
Because the Add/Create button is global, it's not really possible to
know *where* to create the new record, and the current design can't
really deal with a record being edited outside of all groups.
An option might be to create a dedicated empty group for that, but the
cost/benefit is high and the UI would probably be odd.
lp bug: https://launchpad.net/bugs/1098205 fixed
bzr revid: xmo@openerp.com-20130306102136-2ms7llbt4swka92k
When using the ``set_editable`` feature (context key) from filters
(togglable on/off), the list view would not correctly clean up
(destroy) the form when switching from editable with a started editor
(and form) to non-editable, leading to form fields (in this case m2o
fields being in an incorrect state and trying to query a non-started
autocompletion widget on every click anywhere blowing it up).
lp bug: https://launchpad.net/bugs/1117320 fixed
bzr revid: xmo@openerp.com-20130225135629-8k338gw0arsi6m6j
Otherwise, if a search is performed while creating or editing a line
(e.g. in logged calls, create a line without saving then try to apply
a filter) the edition section (and new line) disappears but the list
remains in "edition" mode (e.g. save/discard button) even though
edition data is missing (trying to save or discard will error out).
bzr revid: xmo@openerp.com-20121210100914-delia5bhmtgrujpu
Because of the "meta" columns (e.g. group name column),
ListView#columns would end up with a different number of elements than
ListView#fields_view.arch.children, and when zipping them together (to
build the form view for edition) things wouldn't match anymore.
It would seem simply filtering out meta columns (and only keep those
actually specified by the view) is sufficient to fix the issue and
have everything line up again. I'm midly impressed.
bzr revid: xmo@openerp.com-20121129131301-scc38i4l55ea7lis
During the creation of a new record (in an editable list), the
prospective new record has a ``false`` id. In a non-o2m, the row under
creation can be selected (checkbox) and deleted (More > Delete),
leading to the request to ``DELETE false`` being sent to the ORM…
which said ORM does not wish to entertain.
Before actually performing the delete request (more precisely
forwarding said request to the listview itself), remove all false-ish
ids from the array.
Also, don't send a request to delete nothing.
bzr revid: xmo@openerp.com-20121119084203-0vz4v9myfizxz88u
move special case in o2m listview to main editable and expand to
correctly fit edition cases, not just work in case of creation
issue: if a row being edited is deleted in an o2m, the form will be
blurred and try cancelling/saving the edition and reloading the row,
but this will only happen *after* the record/row/whatever has been
"deleted" and (amongst other things) removed from the buffered o2m
cache, leading to a tentative read on the server side (usually with a
local id which doesn't even make sense) and thus an error.
Intercept the deletion signal to cancel the edition immediately and
only let the deletion through after the edition has successfully been
canceled.
bzr revid: xmo@openerp.com-20121116164416-8kr39t6jtqy2s3jc
the onwrite handler created an "empty" record with no field value
whatsoever, which'd blow up in the py evaluator. As during creation
(edition of a record where all fields are empty) create a record where
all fields are set to ``false`` so rendering works correctly, and wait
for content refresh to get correct data.
Also added a test for @on_write
bzr revid: xmo@openerp.com-20121112150526-vrr66ms95qbuoped
Only fetch the table cells of the row being edited *after* having
saved a pending edition.
Otherwise, when re-editing the same record (e.g. click between buttons
or on a readonly field), the cells are saved, the record is refreshed
destroying the cells, and when trying to get the cell positions to
position form fields correctly... the cells which don't exist anymore
return 0, 0 as their position and nothing works correctly.
bzr revid: xmo@openerp.com-20121017134351-lpmz27f1iemmsfoq
Altered action button workflow:
* Action callback (passed to ``do_button_action``) now *takes* a
record id instead of closing over it, in case the original list does
not have an id to start with
* ``handle_button`` partially applies the id *it* got to the callback
via ``_.bind``
* Editable list view override of ``do_button_action`` uses ``id`` it
got from ``ensure_saved`` in case it got id=false in
bzr revid: xmo@openerp.com-20120807092317-wk0xyfzrhxc89t94