The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Simple refactor in order to make changes to these line trigger the CI/Security
closesodoo/odoo#107032
X-original-commit: 3c215581aa1f8f74f2d9daf1e15f30ee750ec3df
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Setting width *and* height attributes allows to reserve some space to
avoid layout shift during page loading. Of course, CSS rules set the
height the user chose, while the width is set to 'auto'. But while the
image is loading, it is best to already reserve some width to reduce
layout shift (like making the menu move or even re-render itself into a
"+" menu).
The chosen values for the space reservation are the ones of the default
logo and theme, but it does not really matter as long as they are
coherent. While the image is being loaded, the chosen user height is
still applied and the 'auto' width rule induces a width that respects
the aspect ratio set by the width and height attributes. That could be a
problem if the real logo has a larger height than width, in which case
the layout shift would be increased because of the arbitrary values set
as width and height, but in most cases, this should reduce it.
This also allows to gain some page speed scoring.
Examples:
=# Logo 200 x 100, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 200 / 100 * 50 = 100, height = 50
-> layout shift of 100 - 0 = 100
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 200 / 100 * 50 = 100, height = 50
-> layout shift of 100 - 118.75 = -18.75
=> Shift of 18.75px to the left, way better than shift of 100px to the
right
=# Logo 100 x 100, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 100 / 100 * 50 = 50, height = 50
-> layout shift of 50 - 0 = 50
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 100 / 100 * 50 = 50, height = 50
-> layout shift of 50 - 118.75 = -68.75
=> Shift of 68.75px to the left, kinda the same as a shift of 50px to
the right.
=# Logo 100 x 200, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 100 / 200 * 50 = 25, height = 50
-> layout shift of 25 - 0 = 25
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 100 / 200 * 50 = 25, height = 50
-> layout shift of 25 - 118.75 = -93.75
=> Shift of 93.75px to the left, worse than shift of 25px to the right
but the case of having a 'portrait' logo is considered less common
than having a 'landscape' logo. Ideally, we should choose the
arbitrary values related to the most common aspect ratio.
closesodoo/odoo#101149
X-original-commit: 73786c5c45202914e02325c19a2afaa47d31c341
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Field name on sponsor are not required. So when we display the image of a
sponsor without field-name it will use the rec_name 'name' that is not set
and so False.
It will crash during rendering of the widget image that use it.
Now we force to use a field required 'partner_name' to avoid the crash.
By default, when you confirm the sale_order from the backend, we copy
the partner name in field name.
Because we use a class avatar to have a max-width of 96, we don't need
to use a image_512, image_128 is enough in most of case.
The max-width option on widget image has no effect on rendering.
In other case where the rec_name is Falsy and we don't provide other name to
the widget, we now use a default 'name' value to avoid a crash:
closesodoo/odoo#88296
Attributeerror: 'bool' object has no attribute 'replace'
X-original-commit: b054dfc715afb225eb032a722ec58e6888b1b905
Signed-off-by: Jérémy Kersten <jke@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
When working on qweb fields it is difficult to find some custom override as
they are never in the right file. Finding them is always a bit of random pick.
Task-2607416
Part-of: odoo/odoo#74171
Vincent Schippefilt