E.g. this could happen when the HistoryBack client action
was unable to restore the previous breadcrumbs item, and
used the Home action as fallback. Could be reproduce by
performing a successful import from an action without
menu and context, such as what you get after refreshing
your browser.
bzr revid: odo@openerp.com-20140107161154-430y7hlf9mvtfyfe
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
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
Looks slightly worse as results don't seamlessly update in-place, but
limits/avoids the risk of quick-typing, hitting [Return] and getting
an incomplete/incorrect query because the completion didn't catch up
(e.g. slow network) and [Return] validated the previously retrieved
completion.
lp bug: https://launchpad.net/bugs/1183746 fixed
bzr revid: xmo@openerp.com-20130605144949-jbzs2hppr6c1djg3
* don't fix facet height so the facet content correctly "grows" all of
the facet and thus the surrounding view
* hard-code the heights of the view-level controls (clear and open
drawer) to avoid both overly large hitbox and their moving outside
of the top-right corner
* add some margins on the facets container to avoid overlaps between
top-level search controls and facet activable elements
lp bug: https://launchpad.net/bugs/1123704 fixed
bzr revid: xmo@openerp.com-20130605105240-h9o03ol7l8dti1yn
Javascript regexps don't provide a DOTALL flag (to make `.` match
newlines) so have to replace `.` by `[\s\S]` hack, as *that* will
match newlines as well as all other characters.
Note: the `m` flag has a different meaning, it makes `^` and `$` match
the start and end of lines rather than the start and end of the
string itself.
bzr revid: xmo@openerp.com-20130516105908-exgtwwf785hrmedo
- guard do_load_needaction to prevent exceptions when
there is no menu to load
- avoid calling do_load_needaction where there is no
menu to reload in the first place
bzr revid: odo@openerp.com-20130503102248-vjl1b8xju9uwfq97
integer/float fields were not offering auto-completion in search views,
making them unsearchable except via advanced search.
This patch adds the missing complete() function and removes the incorrect
value_from() function that did not conform to the 7.0 search view API.
It seemed to be a leftover of the 6.1 search field implementation
of get_value(), wrongly renamed for 7.0.
Also includes corresponding tests.
bzr revid: odo@openerp.com-20130418112001-388op1t8ugr0rhfn
When a record is activated, the listview will do some jiggling around
assigning the ids of internal dataset to the one shared between all
views, this is mostly for the case where one switches from a "grouped"
list view, so the form view only cycles on the "current" group.
Problem is, that internal dataset is not correctly synchronized with
the shared one, so when the id is removed from the shared dataset it
is *not* removed from the internal one(s), and when the switch is made
the ids from the internal dataset are set on the shared one and
reintroduce the deleted record, leading to the form view's incorrect
state.
Fix the issue by updating the dataset's ids list when a record is
deleted from the records tree.
Also extracted some stuff from DataSetSearch's unlink callback so it
can be overridden and is more stable across datasets.
lp bug: https://launchpad.net/bugs/1161210 fixed
bzr revid: xmo@openerp.com-20130416152000-06dbwkgdb8zlf9pc
If there are no grouping field specified *but* group_by_no_leaf is
specified, should call read_group with no grouping fields: will
generate a single group (which can not be opened) for all of the
model.
Necessary for analysis views since individual "records" make no sense.
bzr revid: xmo@openerp.com-20130416092344-2pqog8f7xprn6hsh
Added the missing complete() function and removed the incorrect
value_from() override that seemed to be a leftover remnant
of the 6.1 search field implementation of get_value(), wrongly
renamed for 7.0.
bzr revid: odo@openerp.com-20130328120337-lao4o9i0owsbpysi
The focus() of AbstractFormField should return false if field
is not focusable otherwise it breaks FormView's#autofocus()
Also added checks of existance of the element to focus.
Those errors makes it harder to find other bugs
bzr revid: fme@openerp.com-20130321220636-1pja2ahsdstyl8kz
@include text-to-icon makes the text invisible (and adds an icon), but
some platform apparently don't apply the text's transparency (or
visibility) to its shadow, leading to the invisible text's shadow
still being noticeably visible (an interesting literary idea, an
"invisible" man who still casts a shadow?) as if the text had not been
erased. Furthermore, combined with the 1px font size it made the text
look like some sort of screen smudge or glitch.
Fix by erasing the text-shadow as well as the text.
lp bug: https://launchpad.net/bugs/1158304 fixed
bzr revid: xmo@openerp.com-20130321164741-iakau7g1kfq2mqu4
On click on a filter in the drawer, FilterGroup would just match the
offset of the filter in the group's DOM with an index in the internal
#filters array.
This worked until invisible fields, and then again only for filters
*preceded* by an invisible sibling in the same group: invisible
filters are not rendered in the DOM, so the indexes would get out of
sync.
Fix by using explicit indexes stored in a filter's @data-index and
using that to get the filter object/node.
An alternative fix (but hackier I think): instead of not rendering
invisible filters, render them with display: none. Remains an option
in the future if needed...
lp bug: https://launchpad.net/bugs/1157125 fixed
bzr revid: xmo@openerp.com-20130321155123-211iht7c6zme712e
This is not only dangerous but also
completely inconsistent with the other
db management screens. It also represents
little improvement in terms of usability
for first-time users, since the password
is now mentioned on the comment just above
the field.
bzr revid: odo@openerp.com-20130318155618-z9s2izahnv1j2no6
Olivier Dony
Denis Ledoux
Mohammed Shekha (OpenERP)
Xavier Morel
Xavier ALT
Martin Trigaux
xmo
Michel Meyer
Christophe Simonis
niv-openerp
Anael Closson
Vidhin Mehta
bth-openerp
Christophe Matthieu
Dhruti Shastri (OpenERP)
Frédéric van der Essen
Paramjit Singh Sahota
Thibault Delavallée
Fabien Meghazi
Darshan Kalola (OpenERP Trainee)
Dharti Ratani (Open ERP)
chirag patel
bth
Antony Lesuisse