Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
- This commit fixes a crash that happens when the server receive a
JSON-P call done in two requests (a POST followed by a GET).
The issue is due to the fact that when the first request is done (POST
one) the member `params` is never initialized.
This parameter is then used in the module `auth_signup` on an override
of the method `dispatch` thus crashing the code.
To avoid the crash, we now initialize `params`.
closesodoo/odoo#27369
The adaptation to Python 3 was done with two mistakes: the iteration on the lru
cache does not return keys, and functions are not sortable.
closesodoo/odoo#28870
Implement the getter method in plain SQL. This makes reading company-dependent
fields 33% faster (on 20000 partners, reading 'property_product_pricelist'
takes 3700ms instead of 5500ms.)
closesodoo/odoo#28769
PKG-INFO is generated during the setup phase and is not needed anymore.
Also this file contains outdated informations.
py2exe is not used anymore to build the windows installer.
closesodoo/odoo#28494
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
If all the planets are correctly aligned, it is possible for a model to
not have any xids associated with it, if this happens then the computed
field that calculates the records to be deleted during an uninstall
may mistakingly add records of this xid-less model to the list of
records to be deleted, even if the actual uninstallation won't remove
these records.
opw-1904139
closesodoo/odoo#28388
Previously broken symlinks would cause a FileNotFoundError
exception in the filesystem watcher thread spawned when using the
--dev=reload argument.
This problem appeared when using emacs to edit python files while
they are being watched by an odoo instance for changes. Emacs
creates a broken symlink as lockfile in the same directory as the
python file that it edits.
This commit makes the filesystem watcher silently ignore any
FileNotFoundError that occurs when it tries to open a file.
Fixes #21214, closes#21215
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
In Dominican Republic, only english speakers and the military use 24h time
format. Businesses handle their information using 12h time format with a.m.
and p.m.
closesodoo/odoo#28042
If a user creates a paperformat, he should be able to modify it too.
Employees have no reason to modify the paperformat though (nor create).
Having a malicious employee modifying an existing report may be dangerous.
[CLA] signature for stijnh92
Fixes#26292closesodoo/odoo#27444
Odoo Translation Bot