Before, we used to use selection widget to hide or disable the create and edit of many2one fields, but this is actually an abuse of the selection widget, this is not its purpose
bzr revid: dle@openerp.com-20140220141302-3paib80ixiyi66qg
The following fixes have intentionally been reverted,
as the code has significantly changed and the bugs cannot
be reproduced:
- web_calendar fix (revid:dle@openerp.com-20140214114258-0hcsfdwyl61gph0v)
- CSS fix for buttons (revid:mat@openerp.com-20140213145755-txvtwqbfc83vnw9o)
bzr revid: odo@openerp.com-20140217102806-qg6kwk2jomdvvmlj
On SearchPopupCreation, if we have initial_ids - 1st search_read() will be
missing custom context defined on the field.
1. defined view like this: <field name='my_many2one_field_id' context="{'test': 1}"/>
2. in we expand the list of available item, name_search() has 'test' in context
3. in we click on 'Search More', search_read() is missing 'test' in context
4. if we change filter add/remove item, search_read() will have 'test' in context
Step 3. is wrong, should also have 'test' in context
lp bug: https://launchpad.net/bugs/1209295 fixed
bzr revid: mat@openerp.com-20140311091522-03imwd5rj3rmwapl
Without this a change of record in a form view would not recompute the list of states as well as a change of state due to a button
bzr revid: mat@openerp.com-20140121151255-jke0zbobb0ilpqid
Task 4941
Extracted relevant section from One2ManyList which already implemented
it previously, then created and hooked in m2m list using (inheriting
from) extracted code.
bzr revid: xmo@openerp.com-20131210164443-ur44b8g5gdrt8jt1
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
The widget option 'fold_field' allows to tell the widget to use this field on
the model used for stages to compute the folded selection.
If not set, no stage is folded.
bzr revid: tde@openerp.com-20131127095037-me1cvl272ex1e6r9
Gery Debongnie
Denis Ledoux
Christophe Simonis
Olivier Dony
Martin Trigaux
Xavier ALT
Mohammed Shekha (OpenERP)
Antony Lesuisse
Thibault Delavallée
Xavier Morel
jke-openerp
Michel Meyer
Christophe Matthieu
niv-openerp
ajay javiya (OpenERP)