when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
This rev. reverts 91911159f5
The above rev. was a good idea, except that internal_set_value expects the raw value, while the records attributes can be tuples(for instance, many2one are tuple(id, name) or list of command(one2many, many2many).
set_value must be use here, as all fields (js) override set_value in order to handle their value repr (for instance, many2one fields handle the tuple (id,name).
Besides, avoiding the re-render provides a huge performance improvment, as rerendering fields can lead to xmlrpc calls (for instance, re-rendering a many2one field implies calling the name_get method)
opw-620111
opw-622108
When adding an item to the editable list, the focused field was no longer the first visible field
This is related to revision 4a508885ac
visible_columns list is not ordered
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
IME are ways to input language which can't trivially map to a keyboard
(e.g. CJK language) with a standard-ish keyboard. For japanese IME
this is done by entering text phonetically: text is entered in romaji
and automatically converted to hiragana (or katakana) when it matches
the transcription a japanese syllable (~phoneme?) e.g. to (と). The
text is then split and reprocessed with sequences of hiragana being
converted to kanji (or not), and the possibility to pick the right
kanji when multiple kanji match e.g. for "Tokyo" toukyou -> とうきょう
-> 東京.
But to do the edition, keyboard keys are used. For the japanese IMEs
(tested on Windows, OSX and Linux) [Space] will do the initial
conversion from kana to kanji (and allow selecting an other conversion
or a different kana split) and [Return] will validate the current
conversion (removing the underline marking "unvalidated" kana or kanji
groups).
And that's where the problem hit: IME + browser combinations may or
may not suppress part of all of the event. Firefox will trigger a
keydown of the key which "starts" IME input (e.g. "t") and will
trigger a keyup for the validation key (return), except on Linux where
the initial keydown is suppressed. Inbetween these, it will fire no
keydown, keyup or keypress event but will fire input events (at least
on an input element) every time the displayed text changes.
Meanwhile webkit browsers will, for each press on the keyboard during
IME,
* trigger a keydown with the keyCode 229
* trigger a keyup event with the keycode of the key which was actually
hit
* trigger input events every time the displayed text changes
This include meta-operation uses of [Space] and [Return].
MSIE has the same behavior (including triggering the input event), but
the keydown event is augmented with ``key`` and ``char`` attributes
providing the character matching the key hit to trigger the change.
Although the triggering of the input even is useless for the purpose
of the editable list (especially here, the purpose of validating a
list row with [Return] one fact stands out: keypress is never
triggered during IME operations, hitting the [Return] key outside of
IME will trigger keydow, keypress, keyup but doing so during IME will
only trigger the first and last.
Thus by changing the binding from keyup (return) to keypress (return)
for a line validation, spurious validation during IME text entry
should be avoided. This seems to work correctly on MSIE (Windows),
Firefox (Windows, OSX, Linux), Chrome (Windows, OSX, Linux) and Safari
(OSX), after testing in IE9, IE10, Chrome 31, Firefox 25 and Safari 7,
and a quick test on a task's o2m did not reveal any regression.
note: not all differences between various browser/os combinations were
inspected in details, there may well be further differences which were
not noticed or not relevant to this precise issue.
bzr revid: xmo@openerp.com-20131206124431-q4a9l1gn9wjtmlvz
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
Christophe Simonis
Géry Debongnie
Denis Ledoux
Martin Trigaux
Denis Ledoux
Xavier Morel
xmo
niv-openerp
Vijaykumar Baladaniya
tsabi
Fabien Meghazi