One of the most costly part of a page loading when the ormcache is cold
is computing the assets node, the unique identifier of an attachment to
validate whether the existing attachment is still valid with the current
version of the static files.
This operation needs to glob assets path in the filesystem,
get the modification date, check attachments, ...
Right now this task is not really optimized and can take some time
because of an excessive number of glob on the filesystem, unnecessary
exists to define absolute path, double computation of file list and
modified times when getting js and css bundle separately, ...
A list of modifications mainly discussed in the pr message are made
with this commit to speedup things.
- split css and js unique
- prepare api for an in memory glob
- change api to propagate absolute path and meta information through
`ir.asset._get_paths`-> _get_asset_paths -> `_get_asset_content` ->
`AssetsBundle`
closesodoo/odoo#121159
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since saas 16.1, we added a more visible error information box when the
module system cannot find some dependencies, or if there is an error in
the JS code. This error box is very useful to understand a lot of
typical devlopment issues. However, it was occasionally displayed in
production code.
However, we sometimes observe that the error information box was
displayed, because the request to load an assets failed with a 404.
It is unclear in which circumstance this can happen, but it seems that
the following elements are involved:
- the user has an open tab with odoo, kept open for a while
- some js code is changed on the server, which causes the previous
assets to be deleted
- the user reload its open tabs, so the browser will load the /web page
from disk, which points to the old assets files
- then it will try to load all assets, with a 404 on one of the script
- the error information box is displayed
This commit intercepts the loading error and stop displaying the error
information box, which is basically the same behaviour as 16.0 and
before. We could force a reload in that case, but it seems dangerous,
since in case of errors, it could easily lead to an infinite loop.
closesodoo/odoo#117625
X-original-commit: 0a44b5b1e008b591a716efd26217c7db7360c37b
Signed-off-by: Géry Debongnie <ged@odoo.com>
The goal of this revision is to re-use the environment among the
different steps of the registry loading,
instead of creating a new environment for each step.
1. Simply To avoid to repeat the line
`env = api.Environment(cr, SUPERUSER_ID, {})`
multiple times in the code
2. This also allows to share the context among the different
steps. This is not yet used in this revision, but it could
be, for instance to avoid the current repetition to add the keys
`install_module`, in `convert_csv_import` and `xml_import._tag_record`
Part-of: odoo/odoo#108254
When the QWeb `<template>` loading test was introduced at [1], the
`test_website` module did not exist yet, see [2].
This commit moves that test and its related data file to `test_website`
to remove the `fake data` noise from the `website` module.
That's one of the two purpose of this `test_website` module:
- Avoid noising the website module with test only data & code
- Encapsulate in a lighter module the module operations tests, but it's
not really the case anymore as those tests are now standalone tests.
See manifest for more details.
[1]: https://github.com/odoo/odoo/commit/9cd982bcc811cacb42f5c08db139043d2734b891
[2]: https://github.com/odoo/odoo/commit/ef03db9edd9472201cb2c08a32d20ff0f33a5fdfclosesodoo/odoo#109349
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Xavier-Do