Xavier Morel
029c866b8c
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
About OpenERP
-------------
OpenERP is an OpenSource/Free software Enterprise Resource Planning and
Customer Relationship Management software. More info at:
http://www.openerp.com
Installation on Debian/Ubuntu
-----------------------------
Add the the apt repository
deb http://nightly.openerp.com/6.1/deb/ ./
in your source.list and type:
$ sudo apt-get update
$ sudo apt-get install openerp
Or download the deb file and type:
$ sudo dpkg -i <openerp-deb-filename>
$ sudo apt-get install install -f
Installation on RedHat, Fedora, CentOS
--------------------------------------
Install the required dependencies:
$ yum install python
$ easy_install pip
$ pip install .....
Install the openerp rpm
$ rpm -i openerp-VERSION.rpm
Installation on Windows
-----------------------
Check the notes in setup.py
Installation on MacOSX
-----------------------
Setuping you first database
---------------------------
Point your browser to http://localhost:8069/ and click "Manage Databases", the
default master password is "admin".
Detailed System Requirements
----------------------------
The dependencies are listed in setup.py
For Luxembourg localization, you also need:
pdftk (http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/)