When two transactions conflicts (eg. deleting same data, see [1]) Odoo
will retry the whole transaction several times hoping for the best.
But when rendering template, the error handling would prevent this
feature. For example a recurring issue was:
- loading quickly two times the /web route
- for each recompute the assets
=> this could lead to 2 concurrents transactions that would delete
previous same attachment (ie. DELETE FROM ir_attachment where id=3).
With this changeset, when getting a template fails because of a
transaction rollback, we let the issue bubble up so our retry system is
used.
So instead of a "500 Internal Server Error" page and in log:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
"GET /web HTTP/1.1" 500 -
... big traceback ...
load could not load template
we would get the requested page without error and:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
SERIALIZATION_FAILURE, retry 1/5 in 0.8920 sec..
"GET /web HTTP/1.1" 200 -
As a side node, the issue was exacerbated in some instances:
- when running a database on another server: assets are recomputed
- when a module was installed/uninstalled: assets may are recomputed
- when updating the source code: assets may be recomputed
- when starting server: requests could be stacked waiting for readiness
- when using google chrome: the "Use a prediction service to load pages
more quickly" option may load a page two times. for example:
-> an URL is entered in address bar
-> a prediction request to it is started URL
-> go to this page (Enter) when that request is not already resolved
-> the prediction request is cancelled and a new request is started
[1] https://www.postgresql.org/docs/9.6/static/transaction-iso.html#XACT-REPEATABLE-READ
note: 10.0 backport of 11.0 #26778
opw-1849167
closes#26785
The override of fields_get adds "virtual" fields corresponding to
groups.
If for example we make "res.users" have inherit "mail.thread", we get
these "virtual" field as if they had "track_visibility", since we do a
"fields_get" with fields having track_visibility expecting to only get
back "track_visibility" ones.
So the system would then fail trying to track visibility on fields like
"in_group_5" and for example a res.users could not be created anymore.
With this fix, we fix the fields_get so it respect the fields we ask of
it.
fixes#22332
opw-1878654
closes#22338closes#26705
Co-authored-by: Wolfgang Pichler <wpichler@callino.at>
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
During an import, account_invoice.py's _onchange_partner_id can return a
RedirectWarning exception, which wasn't properly handled by the load method.
Since it is an Exception, it was expected to have a name field.
We add it as a property so that they can be treated uniformly.
opw 1866965
The dateutil package uses lazy import to selectively expose its
features: `parser`, `relativedelta`, `rrule`, `tz`.
Depending on installed modules and order of initialization, there was no
guarantee that a given feature was already loaded during the preparation
of the action context.
This patch ensures that we always preload the feature set we need, and
only that feature set. This way we have a consistent `dateutil` lib in
the action context at all times.
An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Open the web/database/manager and create a db with a country set.
The country of the first company will be set to the country set on the form
Before this commit, the currency was not set, eventhough it is a field
on res.country
After this commit, we also set the currency of the first company
opw 1869435
closes#26097
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
Avoid sharing of users'groups when writing on multiple users.
When changing groups of multiple users, all implied groups were shared
between written users.
Oversight of new-api rewrite.
Fixes#26036
Do not reload when a temporary Python file is
added/updated/reloaded.
This is to be able to use editors using isolation when saving file.
On save, they create a temporary file which is then moved on the target file.
The temporary file exists for milliseconds only,
and when the change was detected by watchdog and the server was reloaded,
the file already no longer existed on load.
It leaded to `No such file or directory` after the reload.
Before this commit:
* Install module A
* Edit a view from module A, add a custom field
* Uninstall module A
* Reinstall module A
* Try to access the module A's previously modified view
-> Can't access the view, or even sometimes the app at all.
Cause:
When uninstalling module A, the custom field added to module A's is
properly unlinked, however the custom/studio view is not unlinked, therefore
the view references a field that no longer exists, when accessing the
view it will obviously crash (sometimes the traceback is not even
displayed to the user!).
Solution:
Emulate an ondelete cascade for child views only when in uninstall mode.
Make sure to test `None` instead of any falsy value. Indeed, when we
want to explicitly pass a `False` default value, `set_multi` might
select an incorrect default value.
This is for example the case of `_inverse_product_pricelist`, where
`default_for_country` might be `False` on purpose.
opw-1858271
Sébastien Theys