DO NOT FORWARD-PORT: the functionality is not used anymore in v9
Commit aaf9badb filters the returned ids by keeping the domain in the
request. However, `this.dataset.domain` might be empty, while
`self.dataset.get_domain()` will retrieve it from the model.
Since `get_domain` is not always defined on the dataset, we keep
`this.dataset.domain` as a fallback. The fix is not great, and a better
solution should be found in master branch when the web refactoring is
done.
opw-666755
On a first edition of a view list editable, scrolling before the first
edition might cause an issue: the editing fields are higher than they
should.
This commit solves this.
This issue stems from jQuery .offset({value}) function which is broken
if the element we want to position:
- is in absolute postionning,
- is inside a scrolled element in non static positionning,
- has not both top and left css property setted,
- has no ancestor element between itself and the scrolled not in static
positionning.
This issue happens less (and probably not at all) in saas-6 since the
last condition is most often not met thanks to this change:
https://github.com/odoo/odoo/commit/1ccd87a#diff-27c072074221456684bfc5f150ca0bc9R876
This issue of jquery is solved since jquery 3.0.0-alpha1:
https://github.com/jquery/jquery/commit/2d71594
( the issue is shown in https://jsfiddle.net/wpjrnggf/ and we can see it
is solved with jQuery 3.0.0-alpha1 https://jsfiddle.net/L6ykpjgy/ )
closes#8251
opw-647622
When we go from one field to another via the tab key, in the form view what happens is:
{{we get a blur from the current field}}
-> if [[widget was not in state clicked (which can be gotten for example by clicking on a focused field)]]
-> blur event is cancelled,
-> the blur event is set to be triggered soon
-> the clicked state is set to false
{{we may get a focus for the next field}}
-> if [next field get an onfocus event]
-> blur event is cancelled,
So if :
- the state is not clicked and,
- the next field don't get an focus event.
We get a blur event which will either save (if a field value has been changed) or cancel
the form view editing and will hide the current edition, hence losing the focus.
For example, it happens on a readonly fields with field containing an `<a />` tag, on
some browser (for example google chrome), the focus event will not get triggered (it still
work if we were in a clicked state) so we can't cycle thought a list editable cells if there is a readonly field in it.
closes#7446
opw-643718
On a line write in a account.move.line tree view, the on_write return all the
sibling move lines of the written move line. The lines are then displayed even
if they do not match the current search domain.
This fix adds the context on the given on_write callback request, and in
on_create_write use a on_write_domain in this context to filter the returned ids.
fixes#3161, closes#5727
opw-630093
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
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.
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
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
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