Commit Graph
6907 Commits
Author SHA1 Message Date
Julien Carion (juca) 2a37a3d06f [REF] web, base, mail: move res.users.settings from mail to base
This commit moves and adapt the res.users.settings model from mail to base and
and allows to access and modify its content with web's user service.
This allows to access user settings without needing the mail module.

closes odoo/odoo#116005

Related: odoo/enterprise#38360
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
2023-06-22 15:40:43 +02:00
Saurabh Choraria 8e93e0e6e3 [FIX] base: prevent traceback when Portal User Template is not found
When user deletes 'Portal User Template' record from 'res.users' model and when
'action_open_template_user' function is executed at that time traceback is
generated on the user side as well as in the log.

Steps to reproduce:
    1. Install Website module.
    2. Go to settings > Users&Companies > Users.
    3. Remove Internal Users from default filter.
    4. Add Inactive Users in filter and delete Portal User Template.
    5. Go to Website Settings > Privacy > Customer Account.
    6. Click on Free sign up and then on Save button.
    7. Now in Website Settings click on Default Access Rights button.
    8. The error will occur.

Applying this commit will fix this issue.

sentry-4184456381

closes odoo/odoo#125761

X-original-commit: f1906f4bb21a88e0c8008393557a16b098dea3c2
Signed-off-by: Rémy Voet <ryv@odoo.com>
2023-06-20 18:01:56 +02:00
Tom De Caluwé 7f6924e8fd [FIX] core: allow uppercase characters in translatable fields
Identifiers (including column names) that are not double-quoted are folded to
lowercase in PostgreSQL. Before this commit, this resulted in errors when
updating translations for translatable fields, because the query did not
correctly quote all identifiers.

opw-3287428

closes odoo/odoo#125641

X-original-commit: 70ae8de223fc10f6e80dae06b0f6a6f15c198b5f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
2023-06-19 19:17:06 +02:00
Samuel Degueldre 81be42d8f9 [FIX] *: ensure tour tips are correctly translated
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows

In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.

This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.

This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.

In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.

closes odoo/odoo#125284

X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
2023-06-19 13:35:28 +02:00
fdardenne 71ab15e4d5 [IMP] base: store currency_field in the database
Before this commit, it was not possible to create a custom monetary
field without having currencies named `currency_id` or `x_currency_id`
in the model.

With this commit, we store the currency_field from the Monetary field
in the database. This allows to create custom monetary field with
currencies name we want.

A good use case for this IMP is for Studio, we can now create and edit
monetary field easily without storing it as a `float` in the ORM.

Part-of: odoo/odoo#118199
2023-06-19 10:40:38 +02:00
Julien Castiaux 7d1959febc [FIX] core: reset current_thread.dbname/uid between requests
In [HTTPocalypse] the `odoo/service/wsgi_server.py` file has been
removed and its features has been spread to other files. One of the
feature was reseting those few thread-local variables[^1] before
processing any new request:

    if hasattr(threading.current_thread(), 'uid'):
        del threading.current_thread().uid
    if hasattr(threading.current_thread(), 'dbname'):
        del threading.current_thread().dbname
    if hasattr(threading.current_thread(), 'url'):
        del threading.current_thread().url

In [HTTPocalypse] the `url`[^2] is correctly set at its definitive value
at the beginning of the request so there is no need to delete it before
processing.

On the other hand, `dbname`[^3][^4] and `uid`[^5] are only set when the
request is processed by `_serve_db`, i.e. that the user is connected to
a database already. Those values weren't reset at the begining of the
next request so in case that next request was processed by `_serve_nodb`
or `_serve_static`, the dbname and uid of the previous request would
still be present.

This commit restores both `del uid` and `del dbname` at the beginning of
the http stack, before the request is processed.

[HTTPocalypse]: odoo/odoo#78857
[^1]: https://github.com/odoo/odoo/blob/a1361d6629a829fd622f2a1a1b3e5b025050eaf9/odoo/service/wsgi_server.py#L80-L85
[^2]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1987
[^3]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1563
[^4]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/modules/registry.py#L70
[^5]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1582

closes odoo/odoo#125205

X-original-commit: c327c4586243430751100c8980169ae067383b1c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
2023-06-15 19:59:13 +02:00
Julien Castiaux 3160c376bc [IMP] core: --db_maxconn_gevent
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

closes odoo/odoo#125190

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
2023-06-15 19:59:08 +02:00
Romain Derie 202f79dec0 [IMP] sql_db: allow to track queried table on cursor outside --log-sql
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
2023-06-15 18:51:18 +02:00
Romain Derie 984bad4974 [IMP] sql_db: find and log queried table when the query is multiline
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
2023-06-15 18:51:17 +02:00
Florian Damhaut 92a0907484 [IMP] web: graph line, cumulated graph start
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.

closes odoo/odoo#122321

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
2023-06-14 20:20:51 +02:00
Antoine Dupuis (andu) c31beb459d [FIX] tools: Improve docstring of load_xsd_files_from_url()
This is to clarify that the file_name param is not used if a ZIP is
downloaded: in that case, the filenames in the ZIP are used to save
the attachment.

See discussion in https://github.com/odoo/odoo/pull/115720#pullrequestreview-1392562860

closes odoo/odoo#124946

X-original-commit: ae94f14a844352f66490ec326fe2d1a716023891
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
2023-06-14 10:54:47 +02:00
Raphael Collet 7c17e2745a [FIX] base: onchange2() for res.users dealing with reified group fields
closes odoo/odoo#124612

Related: odoo/enterprise#42445
Signed-off-by: Raphael Collet <rco@odoo.com>
2023-06-13 12:49:25 +02:00
Raphael Collet 578a6083e3 [FIX] core: enable read() on new records without origin, as it is used in onchange2
Part-of: odoo/odoo#124612
2023-06-13 12:49:24 +02:00
Raphael Collet 00e86b1552 [FIX] core: new record has one2many field with real records
Part-of: odoo/odoo#124612
2023-06-13 12:49:23 +02:00
Raphael Collet d30b5c0392 [FIX] web: onchange2() format of values in LINK commands
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
2023-06-13 12:49:22 +02:00
Raphael Collet 67a402edb5 [FIX] web: onchange2() copy of sub-x2many fields in cache
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
2023-06-13 12:49:21 +02:00
Raphael Collet 243a2e8d03 [FIX] web: make onchange2() apply x2many commands on existing record values
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
2023-06-13 12:49:20 +02:00
Raphael Collet a980d58e48 [FIX] web: onchange2() did not return default value for x2many field
Make the parameter 'force' in method RecordSnapshot.diff() effective in
the case of x2many fields.

Part-of: odoo/odoo#124612
2023-06-13 12:49:19 +02:00
Rahul Prajapati 54b1cb8bb9 [FIX] base: validation for studio fields compute dependencies
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

closes odoo/odoo#124660

X-original-commit: 9eab433e09aafafd3015f731b9ec449965d97748
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2023-06-13 10:13:29 +02:00
Martin Trigaux 604a47ead8 [IMP] *: remove global ACL
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

closes odoo/odoo#118701

Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2023-06-12 22:39:26 +02:00
Martin Trigaux 53ca9840d8 [IMP] base: remove read on ir.default
And make get private

Part-of: odoo/odoo#118701
2023-06-12 22:39:25 +02:00
Saurabh Choraria 2476a5b1bb [FIX] base: prevent traceback when icon file is not found
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

closes odoo/odoo#124540

X-original-commit: 4b0221800ab75d5573e7066bf8beee14488062dd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2023-06-12 12:41:15 +02:00
Julien Castiaux ade2715910 [FIX] core: jsonrpc sends 400 for non json request
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>
2023-06-11 00:34:31 +02:00
Xavier-Do ca8dc2d9b4 [IMP] base, website: small refactoring
Mainly to simplify website overrides and general api

closes odoo/odoo#121376

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
2023-06-10 11:14:12 +02:00
Xavier-Do 1b9ac0e100 [IMP] base, website: match similar assets.
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
2023-06-10 11:14:11 +02:00
Xavier-Do 6d5d234f15 [IMP] base: better ormcache management
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
2023-06-10 11:14:11 +02:00
Saurabh Choraria 1a1011d78e [FIX] base,website_sale,gamification: prevent quick create of new field
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

closes odoo/odoo#124442

X-original-commit: 9e64211eb4398b25c57d73bc5a92eda88d314bd1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
2023-06-09 13:50:14 +02:00
Maximilien (malb) 96f22bd8f0 [FIX] web: company details
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.

closes odoo/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>
2023-06-09 13:50:08 +02:00
Achraf (abz) ff9da0e9e2 [FIX] base: Add exception info to logger.error
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.

closes odoo/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>
2023-06-09 13:49:43 +02:00
Achraf (abz) 6ddcb44861 [FIX] base: Update non-stored field error logging to include exc details
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.
...
```

closes odoo/odoo#124208

X-original-commit: b0844d2f3c0c9655746b4c16c9b612bae9954618
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
2023-06-08 11:43:36 +02:00
std-odoo c056f858fd [FIX] web: do not keep useless properties keys in definition
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

closes odoo/odoo#124129

X-original-commit: 35c99a9110cec3317f36d4ddffae5196b58939e5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
2023-06-08 09:09:57 +02:00
Roy Le 89924c2edc [FIX] core: avoid error when using env from api.Environment in
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

closes odoo/odoo#124086

X-original-commit: 70fcfa0d9cdf51964fce1a3be31bbd26258e2275
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2023-06-08 09:09:55 +02:00
Rahul Prajapati 8d7e0cefc0 [FIX] base: unlink custom cron after uninstalling model
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

closes odoo/odoo#124175

X-original-commit: b0202488220bd48dd177e9e0601f2f3ba8d7a0f1
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Signed-off-by: Rahul Prajapati (rapr) <rapr@odoo.com>
2023-06-08 08:02:44 +02:00
Jinane MaksoudandAlvaro Fuentes ff33fa9faf [FIX] base: fix read methods for reified fields in res.users
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.

closes odoo/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>
2023-06-07 15:58:45 +02:00
Mehdi Bendali Hacine 2a6696ce02 [ADD] base: Add country states for Saudi Arabia
closes odoo/odoo#124021

X-original-commit: d9cc09381156d3c54c875eccfc455ee53d532dcd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
2023-06-07 14:43:22 +02:00
niyasraphy 048f0a53c3 [FIX] base: prevent deletion of group linked to settings field
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.

closes odoo/odoo#123905

X-original-commit: ef3dfd02012e16c88789137f5eb0ec49b22f4df8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2023-06-06 14:48:41 +02:00
Maximilien (malb) c91d9c5190 [IMP] base: adding margin bottom paperformat to wkhtmltopdf
Before this PR, it wasn't possible to add a custom margin bottom into specific paperformat args.

closes odoo/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>
2023-06-06 13:10:39 +02:00
std-odoo b90d471e6b [FIX] base: fix selection properties in list view
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

closes odoo/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>
2023-06-06 11:45:19 +02:00
niyasraphy db8a289384 [FIX] base: search groups with full name
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.

closes odoo/odoo#123723

X-original-commit: 6ef080a4818dd0bb85aa4ef257900522d9e9fbd6
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
2023-06-06 11:45:11 +02:00
Julien Castiaux 27865152bb [FIX] core: missing doc for some subcommands
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.

closes odoo/odoo#121085

X-original-commit: 9c6bac741ff437564e7dbe4d0aa8dbd307b71f8d
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
2023-06-06 11:44:58 +02:00
nni-odoo 84ac1d1093 [IMP] l10n_th: Tax Invoice
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

closes odoo/odoo#123679

X-original-commit: 1cdaa362c9f0377a7ec4929c2f581ccd84ae3b33
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
2023-06-06 03:49:51 +02:00
Olivier Dony 3db7956b4c [IMP] assets: switch to optimized rjsmin minification
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/

closes odoo/odoo#104283

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
2023-06-05 16:16:57 +02:00
Benoit Socias f6814d9c6e [IMP] website: add test about website-specific assets
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

closes odoo/odoo#123662

X-original-commit: fced70f840c98e29675ff41812e76c1883d1d57f
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
2023-06-05 14:50:25 +02:00
Abdelouahab (abla) d10a40b14d [FIX] fields: read unstored one2many field without search function
> 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

closes odoo/odoo#123563

X-original-commit: 7b29e9dff1d5ef97c5fb2a2ae0709bb21fd3fa3a
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
2023-06-05 14:50:03 +02:00
Alvaro FuentesandChong Wang f7fca3faf9 [FIX] core: do not udpate translation terms from text to xml
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"/>
  ```

closes odoo/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>
2023-06-02 23:38:58 +02:00
Pulinckx Pierre (PIPU) 679796dbf5 [ADD] base: Add Client Actions technical view
Adding a new view with Client Actions in settings
available by the technical menu

taskId : 3339472

closes odoo/odoo#123419

Signed-off-by: Géry Debongnie <ged@odoo.com>
2023-06-02 22:29:15 +02:00
niyasraphy 37a7a05c67 [FIX] base: improve logger message
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

closes odoo/odoo#123364

X-original-commit: a7680426edfe7a8980a997c2947e05331254897b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2023-06-02 22:29:11 +02:00
Tommy (tong) 685cb96ec2 [IMP] base: add support to company_dependent for html fields
Issue:

 Html fields cannot add company_dependent

Cause:

 Neven have html type for company property

Solution:

 Add html type inside ir.property

closes odoo/odoo#121243

Signed-off-by: Rémy Voet <ryv@odoo.com>
2023-06-02 22:28:52 +02:00
Ivan Yelizariev 101acf3773 [FIX] core: fix infinite loops with child_of/parent_of
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

closes odoo/odoo#123353

X-original-commit: 2e1adc0c3e33fcf7989d27bb4d1c2e3c019faf2b
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
2023-06-02 17:00:10 +02:00
Martin Trigaux 2afdda2576 [I18N] *: export saas-16.3 source terms
closes odoo/odoo#123046

X-original-commit: 137f5ca0cb703ee953cb01db525362f7a778e6bd
Related: odoo/enterprise#41703
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2023-06-01 11:43:51 +02:00