| Age | Commit message (Collapse) | Author |
|---|
|
This commit introduces a new module system for the javascript code.
Instead of using global (namespaced) variables everywhere (like
openerp.web.whatever, ...), each file declare one (or more) module
with its dependencies. Each module will be loaded after its
dependencies, and will be given a reference to the return values.
This change is a massive departure from the way the client worked
previously. It will sadly break some/most history, but I am sure that
the future git ecosystem will allow you to easily browse the history
past this revision (one can dream).
This commit feature:
* main namespace is now odoo instead of openerp
* a way to define modules and dependencies (inspired by requirejs)
* many files have been splitted in simpler subfiles
* basic support for debugging in odoo.__DEBUG__
* no global variable (i.e. nothing in window.openerp)
* many bug fixes, many new bugs
Future vision: this modularization should simplify future code
development, simplify debugging and will allow a serious testing effort
|
|
|
|
|
|
|
|
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.
|
|
ignore .po and .pot changes
|
|
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 91911159f5bc12046d791744ff23562378be047f
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
|
|
If one click on empty area of button at that time we should set focus of the field based on field order.
Do not evict record from dataset, otherwise it will go to read from database and will do server call for read, if user is cancelling in one2many then there is no need to read record from database, this will also fix the issue of unorder execution of event trigger. (opw 613100)
|
|
|
|
|
|
Sometimes, focus_field could be a button, and in such cases, we should not focus on it
opw-612045
|
|
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
|
|
|
|
dynamically show and hide the fields
|
|
|
|
When adding an item to the editable list, the focused field was no longer the first visible field
This is related to revision 4a508885ac043b25465aa5741955082aa66ce949
visible_columns list is not ordered
|
|
63ea0df73ffd6bf659b2ef29cdc3d3387bec92ac
|
|
new row
Before, the focus was set on the first row, and, thererefore, if the list was enough long, it jumped out and the actual new row was hidden
|
|
revid:dle@openerp.com-20140409093422-imrg2hqozf46kj8d
bzr revid: dle@openerp.com-20140409093616-3060or02z8zmv8tm
|
|
bzr revid: dle@openerp.com-20140408120141-f1fx2e9e8vqatccx
|
|
revid:chs@openerp.com-20140116154645-sy4zhdgqc48xaqbx
bzr revid: dle@openerp.com-20131224112612-5gjit5uu1aaaqstx
bzr revid: dle@openerp.com-20140103094532-mbczi9ssr3gc90o1
bzr revid: dle@openerp.com-20140108105833-gblxqdw3if1gt35k
bzr revid: dle@openerp.com-20140115121441-bskbyxxbc09ubavh
bzr revid: dle@openerp.com-20140115165506-yuux9km39gbv7k4n
bzr revid: dle@openerp.com-20140116161415-0y9m0kgavcytzj9z
|
|
bzr revid: xmo@openerp.com-20131218152626-kexq1wudvjwnh962
|
|
attribute) for readonly changes, using effective_invisibility instead of invisibility attribute (opw 601970)
bzr revid: mat@openerp.com-20131217104111-u9bnqvz7rd5rzwnc
|
|
writable in editable list view
bzr revid: mat@openerp.com-20131210155703-2mzqa2mch46nxpcj
|
|
listview
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
|
|
Still has some retro-compatibility for other addons.
bzr revid: nicolas.vanhoren@openerp.com-20130806125022-bzjbtn0nqk40ak4g
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130725103301-65nld10p1if7k0zt
|
|
bzr revid: nicolas.vanhoren@openerp.com-20130725100749-0i82gf3k3nvt4r44
|
|
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
|
|
non-editable list
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
|
|
bzr revid: vba@tinyerp.com-20130204084307-8qremz8qi1qcwhfe
|
|
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
|
|
lp bug: https://launchpad.net/bugs/1084306 fixed
bzr revid: xmo@openerp.com-20121129140109-bwx1njhyqfenc2d3
|
|
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
|
|
bzr revid: csaba.toth@i3rendszerhaz.hu-20121129115306-ifncjymnmuk989eq
|
|
Maybe some missed, but most of them marked.
bzr revid: tsabi-20121129002200-20tppzvh0ap5tfwe
|
|
To do so, extract sort handling to its own method (bound using the
events hash) and override-and-disable in editable.
bzr revid: xmo@openerp.com-20121127094109-mojnq50mzsrcj3q0
|
|
setted to true. This is because search popups should not be editable. 'search more...' was not clickable in fields with many2many_tags widget and default tree view with flag editable setted
lp bug: https://launchpad.net/bugs/1080997 fixed
bzr revid: dle@openerp.com-20121120153958-jopkpxmz38b78phj
|
|
useful
bzr revid: xmo@openerp.com-20121119084533-6qnktzmh19kfwtoo
|
|
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
|
