The Gevent worker has specifc needs in term of maximum concurrent
connections to the database and those needs are not compatible with the
default limit that is primerly set for http workers.
This PR makes it possible to supply a configuration dedicated to the
gevent worker.
task-id-3193565
task-id-2146565
closesodoo/odoo#125190
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit introduced a way to log queried table on cursor without
having to be in `--log-sql` mode.
It will be used in next commit to add complete performances tests which
will ensure the correct tables are accessed when a page is requested.
This is useful as right now those performances tests are only doing a
check against the SQL query number without ensuring the queries are the
correct ones.
As a result, one could introduce an improvement which would reduce the
queries (-2) but break another previous improvement (-2) which would
add back those queries (+2). Since the query count would be the same
(-2+2), it would be undetected, instead of being fixed directly and
keep both improvements (-2-2).
See next commit for concrete example(s) and use of this improvement.
X-original-commit: 8ef6137a34aa35182399a2bd4b20dd57479ab2e7
Part-of: odoo/odoo#124939
Before this commit, a multiline SQL Query (crafted, as the ORM is one
lining the queries) would not be catched in the `sql_from_log` and
`sql_into_log` variables, despite being shown and counted in the request
queries (unless the `into` or `from` part of the query is on the first
line).
At the end, not only the query was not listed in this table report but
if you sum the table report queries, it would not match the shown query
count.
This is the case for the `website_visitor` UPSERT query:
```sql
WITH visitor AS (
INSERT INTO website_visitor (...)
VALUES (
..., (
SELECT id FROM res_country WHERE code = NULL
)
)
ON CONFLICT (access_token)
DO UPDATE SET
...
RETURNING ...
)
SELECT id, upsert from visitor;
```
This commit is allowing the `into` and `from` part of the select to be
detected even if it's not part of the very first line of the query.
As a result, since a SELECT and an INSERT could be part of a same query,
we exclude the SELECT to be considered as a SELECT query if an INSERT
was already found in this query.
This will allow to have table query count log be in par with the query
count number (except for the `base_registry_signaling`, see note below).
It will also be helpful in next commits which will introduce a way to
access those logged queried table in the testing suite without being in
`--log-sql` mode.
Note: the SQL query on `base_registry_signaling` (which occurs every
time to check if the cache should be invalidated) is not tracked
either due to how it is build, it doesn't seems really needed to
have this one shown in the table logs. See [1].
This commit also remove the `lower()` usage and use the `IGNORECASE`
flag from `RE` instead.
[1]: https://github.com/odoo/odoo/commit/4aeba0c12e0512e537178e6cba0993a11f001ec3
X-original-commit: 255aa168bef5d63480e88b4d34511e3aac910f49
Part-of: odoo/odoo#124939
This PR allows a line chart in cumulative mode to start at some
non zero value if some conditions are met.
For this, the attribute "cumulated_start" should be set to true on
the arch root node of the graph view. If set to true, if the first
groupby (if any) is a date/datetime field "d", and if the domain
contains a condition based on "d" - thus possibly excluding some
groups with "d" values inferior to the least "d" value found in
the fetched groups - the initial value for the cumulative chart
will be set to be the aggregated value for those excluded groups.
closesodoo/odoo#122321
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The LINK command must include the corresponding record data in the
web_read() format instead of the diff() format. The real difference
shows up in x2many fields: web_read() returns them as lists of dicts (or
list of ids), while diff() returns them as lists of commands.
Part-of: odoo/odoo#124612
onchange2() reads the origin record from database, and copies its field
values in cache on the corresponding new records. The copied x2many
fields must use NewId instead of their real id.
Part-of: odoo/odoo#124612
When doing an onchange on some existing record, the x2many commands must
be applied on the current x2many value of the record. When doing an
onchange on a new record, the x2many commands must be applied on empty
x2many values.
Part-of: odoo/odoo#124612
Before this commit:
`id` cannot be set as the dependency for a field's compute method.
So, when a user configures `id` as a dependency for a studio field's compute,
there is no error shown to the user and
the field is saved with `id` as a dependency.
After this commit:
It will throw a `UserError` to the user.
sentry-3979435039
closesodoo/odoo#124660
X-original-commit: 9eab433e09aafafd3015f731b9ec449965d97748
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When user tries to import a module which does not consist of an icon and then
when user tries to access that module the error occurs.
Steps to reproduce:
1. Install web_studio.
2. Import a module(without icon) from apps > import module menu.
3. Now search that module in apps and click on module info.
4. The error will occur.
Applying this commit will fix this issue.
sentry-4206999375
closesodoo/odoo#124540
X-original-commit: 4b0221800ab75d5573e7066bf8beee14488062dd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
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>
Julien Castiaux