Send a request to any json-rpc route with a HTTP header
`Content-Type: application/json-rpc` but send non-json or
non-jsonrpc data in the body. The application crashes with
a 500 Internal Server Error instead of a 400 Bad Request one
closes odoo/odoo#124571
Closes: #122048
X-original-commit: a1b83b07996f3fe4744474ff4023a3a2ce17ac7f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
1. move cache to _get_asset_paths
The `_get_asset_content` cache has many cache key that are related to a
posprocessing of the `_get_asset_paths` result, the heavy part of this
method. Moving the cache to _get_asset_content will have the benefit
to create less duplicates entries in the ormcache as well as less cache
miss.
To simplify even further, the css and js parameters are removed since
they only filter the output of get_paths, the heavy part of globing the
file will be done before that. Anyway, they are both true when called
from _get_asset_content, and the only other call, in
`_get_related_bundle` don't really need to filter them since it is not
a critical part regarding performance, and the funtional result will
stay the same.
The initial orm cache key was using `_get_template_cache_keys`, a little
overkill and possibly creating duplicates entries again. The only
context key needed is website_id for `_get_related_assets`.
Note that it is not really enough, the orm cache key should actually
contain `request.session.get('force_website_id')` as well has
`request.httprequest.host`. This will be addressed latter since a nicer
solution would be to have website_id as a unique parameter computed
earlier.
2. better _get_asset_paths cache key
The orm cache key was simplified in previous point but there is still
one concern, the website_id depends on more parameters than that:
- request.session.get('force_website_id')
- request.httprequest.host
- existing websites
The idea here is to call `get_current_website` instead of using all
parameters that could define the webiste.
In the same spirit of `_get_template_cache_keys` `_assets_path_params`
can be overriden to give extra params that are usefull to list assets
path. Those params are computed before entering the method
`_get_asset_paths`. This may latter put at a higher level latter, in
get_asset_node, to simplify the _generate_asset_nodes_cache key.
3. better assets_node caches key
The main purpose of this part is to improve ormcache containing assets
nodes. The ormcache key contains
- to much context key
- missing session/host/env info
- unwanted boolean options.
- keys leading to the same cache value
The main goal being to reduce the size of the cache keys, decrease the
number of cache entries and improve the cache hit.
This will also make the behaviour more coherent and hopefully less bug
prone because of mismatch in parameters.
The main reason of the orm cache is the slowness of the validation of
the assets. This includes:
- listing files (dedicated orm cache)
- computing version
The cache key was depending on
- `debug`
The only relevant value for debug is "contains assets"
We dont need to differ between debug='', debug='1', debug='test',
and 'debug=assets', 'debug=tests,assets', ...
- `defer_load`, `lazy_load`, `media`
Those values are only useful to generate html node, a leightweight
operations that does not really needs to be in cache. `media` was also
used in the generation but it looks useless if we have the media on the
node. THIS NEEDS TO BE VALIDATED but in any case, since media is not
used to generate the url, it doesn't make sence to use it in the
generation.
The main idea to remove them from the ormcache key is simply to generate
the nodes outide the ormcached values.
-`async_load`
This one is similar to `defer_load` and `lazy_load` but it looks like
it wasn't used anymore. This was simply removed
- context.get('lang')
The only information needed is the direction, rtl or ltr. This means
en and fr languages, despite sharing the same css assets, will duplicate
the ormcache entries.
-`_get_template_cache_keys`
Only the lang and webiste where really relevant in this flow. Other
keys are actually useless in this flow.
Some information used in the generation where not in the orm cache key
- `self.env.user.lang` if there is no lang in the context
- `request.session.get('force_website_id')`
- `request.httprequest.host`
- ...
The proposed solution is to:
- extract any informùation needed from thecontext, request, environment
before entering the ormcache, reduce it to the minimal possible set of
values needed
```
rtl = self.env['res.lang']._lang_get_direction(self.env.context.get('lang') or self.env.user.lang) == 'rtl'
assets_params = self.env['ir.asset']._get_assets_params() # website_id
debug_assets = debug and 'assets' in debug
```
and remove a leightweight part of the logic
```
def _get_asset_nodes(self, bundle, css=True, js=True, debug=False, defer_load=False, lazy_load=False, media=None):
links = self._get_asset_links(bundle, css=css, js=js, debug=debug)
return self._links_to_nodes(links, defer_load=defer_load, lazy_load=lazy_load, media=media)
```
Where _get_asset_links is the cached part, and _links_to_nodes is the
lightweight part generating the nodes based on the `defer_load`, ....
Additionnal notes:
- data-asset-version and data-asset-bundle are removed from the node
since they don't seem to be used anymore since 65d70acdbf
- async_load is removed since there is no occurence of this in the code.
- a small hack is still needed to pass javascript content instead of
links, this is only to manage css compile error and will hopefully be
removed in the future.
- a context key is still in use to generate the bundle, the
`commit_assetsbundle` but it has no impact on content and will hopefully
be removed in the future.
4. Add test for ormcache hit/miss
In this context, hit/miss is about having the same cache key for the
same result. This test demonstrates the current state, were entries are
create in the ormcache only if the key is really different and will lead
to a different result.
5. remove cache invalidation
This cache invalidation is quite agressive since everytime an
assetbundle is updated, all workers will clear their cache.
The concerned cache by this clear_cache is `_generate_asset_nodes_cache`
throug `_get_asset_nodes`.
The cache is ignored, both in dev=xml and debug=assets.
This clear cache was made conditionnal in 553ea82f81 but this does
not solve an issue we can have in production.
Lets imagine a clean solution
- all sources are updated
- all workers are restarted.
The orm caches are all empty, but since the sources
changed, all bundles will be recomputed. This means that every bundle
updated in database with save_attachement will invalidate the cache of
all workers. Rendering a pdf report of any kind using a specific bundle
will invalidate all cache. Starting a debug=assets for the first time
will invalidate all cache, even if the cache is not used in this case.
But for a regenerated bundle we would expect the ormcache to be:
- empty (did not generate the same bundle yet)
- have the same value (concurrent generation of the same bundle)
Having a different value would mean that the bundle was generated with
another version of the sources. In this case it is maybe even better not
to invalidate the cache since it could lead to an invalidation war
between two workers.
The only case where invalidating this cache is useful is when a bundle
changes, Usually if an ir_asset is created, modified, ...
There is still another rare but possible possibility to have a 404 if
the transaction is rollbacked after populating the assets node cache.
In this case, we only need to clear the cache locally in case of
rollback.
Part-of: odoo/odoo#121376
When user tries to quick create a field where model is not specified, the error
will occur.
Steps to reproduce:
1. Turn on developer mode.
2. Go to Settings > Technical > Fields Selection.
3. Create a new record and quick create a field.
Traceback will be generated.
Applying this commit will fix this issue.
sentry-3956146718
closesodoo/odoo#124442
X-original-commit: 9e64211eb4398b25c57d73bc5a92eda88d314bd1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Odoo editor when a html field is empty, we add en empty <br> inside the <p>.
This change broke all if statement checking that company details is empty.
In this commit, we add a function is_empty_company_details that return True if
the company details field contains only a <br> and False otherwise. With this
method, we can check that company details is empty and displaying other thing
that just an empty line break.
closesodoo/odoo#124440
Task-id: 3168705
X-original-commit: 2aaca9afb6c54be3ef87ea38646af90a2599aa6b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
This commit includes the exception
details when logging an error in the registry module.
By importing the sys module and using the exc_info() method,
the commit ensures that the complete exception information is captured
by Sentry.
This modification improves the error reporting functionality
by providing more comprehensive information about the encountered
exceptions. This will aid in debugging and diagnosing issues,
enabling faster resolution of potential problems.
closesodoo/odoo#124318
X-original-commit: 55118b726bcd2532d2a7e67322eccb1ea6b75b7f
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We have many issues with this log, except that with a `logger.error` we
do not have exception information (exc_info).
As mentionned in the documentation above, we cannot use `logger.exception`
in this case because we are not within an exception handler.
However, we can still retrieve the exception information using `sys`
module and the `exc_info()` method.
https://docs.python.org/3/library/logging.html#logging.Logger.exception
```
exception(msg, *args, **kwargs)
...
This method should only be called from an exception handler.
```
https://docs.python.org/3/library/sys.html#sys.exc_info
```
sys.exc_info()
This function returns the old-style representation of the handled exception.
...
If no exception is being handled anywhere on the stack, this function
return a tuple containing three None values.
...
```
closesodoo/odoo#124208
X-original-commit: b0844d2f3c0c9655746b4c16c9b612bae9954618
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Bug
===
If we create a selection properties with some options, change the type
to char, and then again to selection, the options are restored.
But, if we just change the type to char, the options of the old
property are stored in the database, and we don't want that.
Task-3346103
closesodoo/odoo#124129
X-original-commit: 35c99a9110cec3317f36d4ddffae5196b58939e5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
pre_init_hook
When reinstalling a module, an error occurred if using env from
api.Environment in pre_init_hook.
Example:
- Module A depends on module B, and model M that created from module A
- When reinstalling module B, an error occurred if using env['M'] in
pre_init_hook
closesodoo/odoo#124086
X-original-commit: 70fcfa0d9cdf51964fce1a3be31bbd26258e2275
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When user uninstalls a module it doesn't unlinks custom crons
which are created by user and it will keep running in the background
and will generate traceback.
So, to fix this we unlink all the custom crons which are related to the
module being uninstalled.
sentry-3929309220
closesodoo/odoo#124175
X-original-commit: b0202488220bd48dd177e9e0601f2f3ba8d7a0f1
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Signed-off-by: Rahul Prajapati (rapr) <rapr@odoo.com>
Before this patch it was impossible to add a reified field to a
res.users list view via Studio.
The internal methods used by search_read are overwritten in res.users
to ignore reified fields.
closesodoo/odoo#123994
X-original-commit: 11e791d68256a5411d727b031930471eceaafb3f
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Jinane Maksoud (maji) <maji@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
before this commit, if tries to delete a user group
which is linked with a field in settings, ie, via
implied_groups in res.config.settings or used in the
field group, there is no restriction and user group
will get deleted.
and then if user tries to access any settings page
the traceback will be shown to user.
after this commit, on deleting any user group
which is linked with a field in res.config.settings,
a validation message will be shown to the user that
the group cannot be deleted as it is linked with
a settings field.
closesodoo/odoo#123905
X-original-commit: ef3dfd02012e16c88789137f5eb0ec49b22f4df8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this PR, it wasn't possible to add a custom margin bottom into specific paperformat args.
closesodoo/odoo#123872
Task-id: 3171683
X-original-commit: 0ea1af531ce8887434893f670b1c1e9f075e88c3
Related: odoo/enterprise#42004
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Bug
===
The web client expects the selection key to be at least an empty array.
(never false), like for a normal selection field, and so if the selection
has been created without an option, it crashes in the list view.
For consistency, we also set an array when there are no tags.
Task-3340671
closesodoo/odoo#123844
X-original-commit: 2e38397c2cfe0e4ed501d4ce7b98f0c47fe6c344
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
before this commit, if user search with full group
name in the search view of res.groups, currently
it returns no results.
* open groups menu
* search for Sales / Administrator
* will return no result
after this commit, searching a user group with
full name with return the corresponding user
group.
closesodoo/odoo#123723
X-original-commit: 6ef080a4818dd0bb85aa4ef257900522d9e9fbd6
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Run `odoo-bin help`, you'll notice that some descriptions are missing,
this commit fixes that.
Run `odoo-bin shell --help`, you'll notice that the `usage:` line says
`odoo-bin [options]` instead of `odoo-bin shell [options]`. Other
commands that depend on the server cli are broken too. Fix those too.
closesodoo/odoo#121085
X-original-commit: 9c6bac741ff437564e7dbe4d0aa8dbd307b71f8d
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When an invoice is issued in Thailand, the Revenue department will make a note that taxes need to be paid. This is important for both corporate tax and VAT purposes. A tax invoice is important to be generated and should contain the title "Tax Invoice".
On top of that, the tax invoice should also contain the information on supplier's tax id number (headquarters or branch number). In this case, we set the original Odoo invoice to be labelled Tax Invoice and create another invoice called commercial invoice.
2879718
closesodoo/odoo#123679
X-original-commit: 1cdaa362c9f0377a7ec4929c2f581ccd84ae3b33
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The C implementation of the JS minification gives speedups between 6
and 55 times faster than the regex-based Python port, depending on
how compressed the input it (which is what our default implementation
does).
This is measurable when generating compiled assets bundle from scratch,
e.g. after installing/updating modules or source code.
As an illustration, the minification of a 2MB JS bundle can be 50x
faster:
```py
import rjsmin
from odoo.addons.base.models.assetsbundle import rjsmin as rjsm
js_source = open("web.assets_common_lazy.js").read() # 2MB JS
%timeit rjsm(js_source)
# -> 339 ms ± 495 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
%timeit rjsmin.jsmin(js_source)
# -> 6.88 ms ± 213 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```
It's also a drop-in replacement, as long as you rjsmin 1.1.0 or better
is available (to support format strings properly, a.o.).
See also the documentation of rjsmin: http://opensource.perlig.de/rjsmin/closesodoo/odoo#104283
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The build does not break if the `with_context(active_test=False)` is
removed from `ir.asset`'s `_get_related_assets`. This access to inactive
assets is actually needed to be able to disable assets on a specific
website, similarly to what is done for `ir.ui.view`.
This commit adds a test to ensures that this feature is not accidentally
lost.
task-3326887
closesodoo/odoo#123662
X-original-commit: fced70f840c98e29675ff41812e76c1883d1d57f
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
> The bug is not present in 16.2+, but we keep the test
To Reproduce:
=============
- on a contact add a one2many field using studio
- in related field choose a field that is not stored and doesn't have a search function implemented
- close studio and notice all the lines of the selected field are listed on the contact even if are not linked to it
Problem:
========
- when searching a field that is not stored and doesn't have a search function, all the lines are returned
Solution:
=========
in this usecase filter the returned lines and only keep the ones linked to the record
opw-3265982
closesodoo/odoo#123563
X-original-commit: 7b29e9dff1d5ef97c5fb2a2ae0709bb21fd3fa3a
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Steps to reproduce the issue:
* In a clean v16 db install base_setup
* Log in into DB, switch language to French (install and activate it)
* Upgrade to saas-16.1
Issue: The main settings page under Companies settings (Sociétés in Frech) shows
```
<span class="o_form_label">Mise en page du document</span> <span class="fa fa-lg fa-building-o" title="Les valeurs définies ici sont spécifiques à l'entreprise." aria-label="Values set here are company-specific." groups="base.group_multi_company" role="img"/>
```
instead of just
```
Mise en page du document
```
The issue comes from this difference, 16.0:
https://github.com/odoo/odoo/blob/fb02720aed0b0be00df8f5d0e1932b948c300b92/addons/base_setup/views/res_config_settings_views.xml#L78-L79
vs saas-16.1:
https://github.com/odoo/odoo/blob/80bc702ecfe6f704af05f9830d272b162018f2ad/addons/base_setup/views/res_config_settings_views.xml#L79
Note that `Document Layout` is used in two different contexts. In 16.0
it comes within an xml/html block containing a `<span>` tag, and more
importantly it is the **text** part of the xml tag. In saas-16.1 the
same `Document Layout` is used as an **attribute** of the `setting` tag.
Thus we cannot blindly assign the whole term (block with tags) to the
attribute when upgrading to saas-16.1, it is only safe to update the
translation from xml to text. Updating a text entry with something that
seems to have other xml elements is unsafe and can lead to the issue
showcased here.
For more context, at the time of updating the terms here is the
situation:
* `closest_matches` is `['Document Layout']`
* `closest_term` is `Document Layout`
* `old_term` is
```
<span class="o_form_label">Document Layout</span>
<span class="fa fa-lg fa-building-o" title="Values set here are company-specific." aria-label="Values set here are company-specific." groups="base.group_multi_company" role="img"/>
```
closesodoo/odoo#123540
X-original-commit: 6cd49293fe4d0d86fbbfa2476e113deadeba7348
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Co-authored-by: Chong Wang(cwg) <cwg@odoo.com>
Adding a new view with Client Actions in settings
available by the technical menu
taskId : 3339472
closesodoo/odoo#123419
Signed-off-by: Géry Debongnie <ged@odoo.com>
before this commit, if the translation import is failed,
in the log it shows "unsuccessfully imported"
after this commit, the logger message is improved and
show file import failed
closesodoo/odoo#123364
X-original-commit: a7680426edfe7a8980a997c2947e05331254897b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue:
Html fields cannot add company_dependent
Cause:
Neven have html type for company property
Solution:
Add html type inside ir.property
closesodoo/odoo#121243
Signed-off-by: Rémy Voet <ryv@odoo.com>
1.
Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.
2.
Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.
STEPS:
In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.
After that open a shell and type:
```
env['res.partner'].search([["user_ids", "child_of", 9]])
```
BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception
---
opw-2729740
closesodoo/odoo#123353
X-original-commit: 2e1adc0c3e33fcf7989d27bb4d1c2e3c019faf2b
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce:
- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
task, Project = P > Save
Issue:
When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.
When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.
Solution:
When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.
This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.
[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b
opw-3183912
closesodoo/odoo#123198
X-original-commit: 26031c452a7d92f35270cb04a4f37b26ff6bcc99
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
When the value of fields is getting None. And no value is assigned to the
`field`. So the traceback will be generated.
In this commit, we will assign a default value to the field if the field gets a
None value. So that it won't get a None value in any case.
sentry-4211843089
closesodoo/odoo#123193
X-original-commit: 3e652808305d3ef4674963195f3c7cdf91b37654
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Archana Vaghasiya (arva) <arva@odoo.com>
Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session
cookie duration was set to 3 months, but the server-side garbage
collection of inactive session was reaping them after 7 days of
inactivity. The cookie lifetime was essentially superseded by the
server-side GC.
After https://github.com/odoo/odoo/pull/78857 these limits were made
consistent with each other, but the lifetime value was kept at 3 months,
which is a bit too long as a default.
This commit changes the default SESSION_LIFETIME back to 7 days for both
limits.
In addition, since the server-side GC is now implemented by a
database-specific cron job, this commit introduces an optional system
parameter `sessions.max_inactivity_seconds` that can be set to override
the default server-side GC threshold, to make it shorter.
Note 1: the ICP does not modify the cookie lifetime which will remain set
to the default 7 days. This means normal browser sessions won't stay
alive for longer than 7 days of inactivity. So `sessions.max_inactivity_seconds`
can't be effectively set to a longer expiration time.
This seems like a reasonably safe default.
Note 2: the session GC happens during the execution of the autovacuum
cron job ("Base: Auto-vacuum internal data") which is scheduled once per
day by default. When setting a small `sessions.max_inactivity_seconds`
value, it may be necessary to increase the frequency of that cron job
accordingly.
closesodoo/odoo#122964
X-original-commit: 05ff9a2db32c2fb1afa107ac005423218f452290
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Currently when a server action causes an error it raises an Exception
which will be caught by sentry and causes unnecessary traffic.
So, we stop catching exceptoins from server actions which are supposed
to be generated by User's Mistakes.
sentry-4169384356
closesodoo/odoo#121707
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since https://github.com/odoo/odoo/pull/121355,
add_to_compute on no-store compute field, lead to recompute the field
at the end of request and it can lead to some non deterministic bug
(compute with a bad context by example).
Avoid to add_to_compute no-store or no-compute fields.
closesodoo/odoo#122973
X-original-commit: 533193106e6c9460d741e504babc7591cb935939
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- set up a header with company logo
- print 20 sale orders in arabic
Bug:
header disapears on most pages
Fix:
add a setting to allow users to increase the delay before printing
opw-3217155
closesodoo/odoo#122983
X-original-commit: 68f7cbd15df7839aab146023399da1570b12b441
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: base
In the cron updating challenges goals, we were historically filtering
in records of users that logged in since the last update. This doesn't
work because sessions can last a long time, so users are active between
cron runs but their goals are not updated and stale reports were sent.
We temporarily fixed this in v14.0 by updating all goals for internal
users, but this can lead to unnecessary computations too, and still
misses goals of active portal users.
Instead, we are here using the `bus.presence` records to track user
activity, combining it with the session lifetime to avoid indefinitely
fetching old goals that couldn't need an update.
This works for both internal and portal users.
Note: we update stale base comments in favor of exposing bus.presence
to guide developers.
Task-3148858
closesodoo/odoo#121763
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).
Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.
opw-3128771
closesodoo/odoo#122884
X-original-commit: 34e97b4c65b7392576d94b870e22e74df14f9dd2
Signed-off-by: Rémy Voet <ryv@odoo.com>
The 'frontend_lang' cookie is used to 'cache' the user's preferred lang.
We want to make sure that this language preference is preserved for a
longer period of time than just the life of the browser. This means that
even if you quit your browser and come back into the year, your
preferred language will be used, until you choose to remove your cookies.
The 'utm_*' cookies are used to 'track' where you are coming from on the
instance. The purpose of these cookies is to know the tracking value
to improve the overall user experience or compute the profitability of
some campaigns. Now we keep these cookies for 1 month.
closesodoo/odoo#122573
X-original-commit: 058e0abcf621796bf23d8dcaaf3b2297f632b5fd
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit:
- Improves the structure of this module as it was broken and
not appealing:
* Text alignments and font sizes were improved
* Card structure instead of a list
* Filters and search are now grouped on top and take less space in
the page
- Adds a specific mobile view for the filters was implemented offcanvas
as the current mobile filtering was not optimized.
- Adds an option to show/hide address in the resellers/partners list
- Makes the option to show the map visible/not visible depending if the
database contains a google maps API
- Makes this module more consistent with the rest of the front-end
modules.
task-3083706
Part-of: odoo/odoo#109752
Followup cleanup of https://github.com/odoo/odoo/pull/106620 where
Datamatrix of pylibdmtx was replaced with built-in reportlab
ECC200DataMatrix option. For stable compatibility, some parts could
only be deleted in master, so let's delete them now.
closesodoo/odoo#122704
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since _search return a query object, we cannot slice it. So we listify
it.
Thanks to XMO and RYV for their very valuable input.
closesodoo/odoo#122589
X-original-commit: 2e51b638232aff90405f318abb849f8b8db38496
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the registry was entering test_mode in setUp,
leading to a hole during the setUpClass with a registry not in test mode
at this moment.
closesodoo/odoo#122585
X-original-commit: 993e4d2f98b9982eb64123d6cd0de8cc3b2056f4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since changes made in https://github.com/odoo/enterprise/pull/41117 we
cannot provide icons for menus in an other format than png. As it was
allowed before to use SVG, we don't want to restrict to only one format.
Before, it was trying to gess the mimetype based on the image content
which is not also the best case.
So as the icon is a binary field store=True, we can just take the
mimetype from the attachment.
closesodoo/odoo#122580
X-original-commit: 044e6b680bc988708a9bbcc3c93dabf787c4a190
Related: odoo/enterprise#41529
Signed-off-by: Masereel Pierre <pim@odoo.com>
Install and then uninstall the utm module via the web client, you get a
traceback because the ir.http override of the utm module is still
present in the registry altought the module is not installed anymore.
The problem affects all modules that override the _post_dispatch method
of ir.http, it is not limited to UTM.
The problem is that, after the uninstallation, a new registry (without
the uninstalled modules) is created but the old registry was still used
by the HTTP stack.
closes odoo/odoo#122519
Closes: #121755
X-original-commit: 979844600a0bc5ea8b63cf4d58c7aba5133e82f3
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
`tocompute` in the `Transaction` contains store field on records to
be recomputed. No-store compute fields are directly invalidated from
the cache when a dependency changes (see `BaseModel.modified`).
In fact, `_recompute_field` was actually doing too much for nothing.
Also, it may invalidate caches of compute no-store fields for no reason
(e.g., if they are searchable). Remove the part for field compute
no-store field. And prevent `_recompute_field` callers from calling it
with no-store fields.
closesodoo/odoo#122147
X-original-commit: ba9ccb07fb12558667db97b866df492fd0f5ba4d
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
In specific situation, unlink can lead to raise a `RecursionError`:
- The model `A` has a many2one `b_id` field toward a model `B`.
This field is set with `ondelete='cascade'`.
- The model `A` has one **store** related field **no-sudo** named
`a_related` (`related='b_id.b_other_field`).
- With `ir.rule` on model `A` with a domain containing `a_related`
You have one record B `b_1` with 20 records A linked to it
(`a_1, ..., a_20`). When you try to unlink `b_1`:
Stack:
File "...", line 543, in ...
b_1.unlink()
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3594, in unlink
self.env.flush_all()
=> At this point, `a_1, ..., a_20` have already been deleted from the
database because of the 'cascade' deletion. But the ORM doesn't have
any information about this, and `a_related` (for `a_1, ..., a_20`) are
flagged to be recomputed (because it depends on `b_id.b_other_field`)
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
self._recompute_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
=> `self.compute_value(recs)` raised a `MissingError` before recalling
`compute_value` with only the first `record` (but others are still in
the prefetch)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
=> `a_related` of `record` is removed from to_compute, but only the
first record, not the rest of the records present in the prefetch set.
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
=> `_read` tries to read the first record + others from the prefetch set
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
self.with_context(active_test=False)._flush_search([], order='id')
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
self.env[model_name].flush_model(field_names)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
self._recompute_model(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
self._recompute_field(field)
=> This is where the recursion starts, record compute will move forward
one by one. But sadly, the stack grows very fast, and with only a few
(already deleted) records to recompute, the issue will be generated.
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
self.with_context(active_test=False)._flush_search([], order='id')
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
self.env[model_name].flush_model(field_names)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
self._recompute_model(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
self._recompute_field(field)
How to fix it:
Move the logic of the MissingError of `_recompute_field` inside the
`recompute` directly.
X-original-commit: c2aac02ac4f8c5cc4a9324134535393bd97338ce
Part-of: odoo/odoo#122147
This reverts commit 9e71094582ec4c9b719431e77538da8f91ffa9e3.
Why?
- It is useless in 16.0, the bug it claims to fix should not exist. In the
commit explanation the sentence 'this calls `_read`, which flushes the
field we're trying to read' is wrong, since
https://github.com/odoo/odoo/pull/66938 (merged in 15.5). (It is still true
for fields that are in an ir.rule, but it sounds very unlikely to have
a recursive field in ir.rule that causes trigger the problem)
- It creates worst errors (infinite loop for recursive field computation on
missing record - Next commit).
- Also, it looks like a dangerous fix that can hide or trigger new
issues.
X-original-commit: 4a46c1049a4cdc15f0e211d228fb976ba7a0173d
Part-of: odoo/odoo#122147
Before this PR:
The only way to neutralize the database is running cli command neutralize
After this PR:
There is a new checkbox "neutralize database" in Duplicate database and Restore database dialog that neutralize the database after duplication/restore.
I also moved the neutralization code to the external module so it can be called also outside the cli .
closesodoo/odoo#122185
X-original-commit: 616740e9d09b3d0376be43ed1489e390f6f5823e
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this patch the naive dsn parser `_dsn_to_dict` would choke
on `application_name` containing spaces or the equal sign.
closesodoo/odoo#122212
X-original-commit: 3573fe0726f8dde1c5714b7d501f6c43d97ce731
Signed-off-by: Fabien Meghazi (fme) <fme@odoo.com>
Current behaviour:
If we add a blockquote in the `website_description` of a product on
the e-shop, we cannot checkout the product. Silent HTTP 400 error
code, due to an exception raised by
https://github.com/odoo/odoo/blob/bf772181933ce5334da35c8368455963b2478399/odoo/fields.py#L1987-L1993
Expected behaviour:
You should be able to checkout products even if they have blockquote
in their `website_description`.
Steps to reproduce:
- Install eCommerce, sale_quotation_builder (issue is present only
after installing sale_quotation_builder)
- On a product, with the website editor, add a `blockquote` to the
description of the product > Save
- In a private browser window, as public user, visit the product on
the e-shop and try to checkout with it.
- Observe there is no visible error, and we do not proceed in the
checkout process.
Reason for the problem:
The exception mentioned above is triggered when there is a
difference between the html content that is saved in the DB and after
sanitization, meaning that someone with escalated privilege saved
the HTML content by overriding the sanitization with
`sanitize_overridable`. In our use case the only diff is the
presence of the attribute `data-o-mail-quote-node` which is removed
after the sanitization.
Fix:
This issue can be resolved two ways:
1) Adding `data-o-mail-quote-node` to the list of save attributes,
meaning it will not be removed during the sanitization process.
Since this is an attribute that we add on `<blockquote>` nodes,
it can be considered safe, just like `data-o-mail-quote`.
2) Remove the attribute sanitization of the `website_description`,
just like it is done in the website_sale module.
Since the `website_description` and `quotation_description` are both
computed from one-another, they should have the same sanitization
level.
I am implementing both solutions, 1) because adding the attribute to
the safe list seems safe in general, and may prevent future
issues of this sort. 2) because it is the root cause of the issue,
since the bug is present only after installation of the
`sale_quotation_builder` module.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3297237
closesodoo/odoo#122154
X-original-commit: 23022144cb1a338db05870b28f17360b92c46a9c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Julien Castiaux