Adds `id` in the `mail.activity`'s order to force deterministic order in
case multiple activities have the same deadline.
Not having a deterministic order can cause issue when tests check
activities' values but don't ensure they are sorted also by id.
closesodoo/odoo#120034
X-original-commit: b0a99bde8efef287f3ed89afb9da2a67233d4bd8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
As a bonus, add cross-tab update for current user in chatter.
Part of task-3265211
closesodoo/odoo#120018
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this PR, link previews where not updated when a user was editing a
message.
This clear the current link previews and reprocess the updated message.
closesodoo/odoo#119917
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The opportunity is taken to clean the methods to make the override
actually possible.
Part of task-3265211
closesodoo/odoo#119942
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit focuses on removing all references to discuss.channel from
controllers of mail module.
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#119523
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit focuses on removing all references to discuss.channel from
code located in /models of mail module.
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#119413
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
this commit removes unnecessary modal that does not let users create
a new users from apps like crm, sale, etc. Now instead of giving requests
that lack email redirectWarning, we open user creation form where user must
set email up.
Reason behind this change is the fact that login is required at the model level,
so the manual checks for this value is not necessary anymore.
task-3262468
closesodoo/odoo#119508
X-original-commit: 7796e8ca971167a96b23baa4b57056c2007ea8b4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
A new `_track_set_author` method is now available to explicitly set the
author of the tracking messages.
Related Enterprise PR: odoo/enterprise#38986closesodoo/odoo#117073
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Configure incoming mail server and set it to create X record
on incoming mails (X can be any model with a chatter)
- Create a CSV file and set the encoding to UTF-16
- Send the CSV file through Gmail to the Odoo instance
- Go to model X and open the created record
- In the chatter, click/download the CSV file
- Open the downloaded file with Geany (or any file editor that can
show the file encoding)
Issue:
The file encoding is not the same as the original file (utf-8 instead
of utf-16).
Working with Outlook.
Cause:
The difference between Outlook and Gmail is that Gmail provides the
charset of the file.
The content of the mail is retrieved using `email` python lib.
The lib will try to retrieve the charset of the file and fallback
on `ASCII` if not available, then return the decode content.
```python
def get_text_content(msg, errors='replace'):
content = msg.get_payload(decode=True)
charset = msg.get_param('charset', 'ASCII')
return content.decode(charset, errors=errors)
```
Example:
content = b'd\x00a\x00,\x00,\x00,\......'
Outlook:
charset = 'ASCII'
return => 'd\x00a\x00,\x00,\x00...'
Gmail:
charset = 'UTF-16LE'
return => 'da,,,,,\n,,,,,\....'
In the post process of the attachment, the content is encoded in
'utf-8' (to then encoded in base64) before creating the attachment
record.
Content encoded to 'utf-8':
Outlook: b'd\x00a\x00,\x00,\x00...'
Gmail: b'da,,,,,\n,,,,,\n....'
Therefore, when writing the file on the disk, the encoding is based
on the binary content.
Solution:
When parsing the mail, add the encoding charset to the `info` variable.
Then, when creating the attachment, use the charset in `info` (or
fallback on 'utf'8' if no charset set) to encode the content.
opw-3089009
closesodoo/odoo#118694
X-original-commit: 2d1b13e68d8bb204ecfe12a9d3db519c4264592c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Templates could previously be created for abstract models.
The methods are not written with that in mind and most useful ones will
raise an exception when calling them on that template.
task-3162320
X-original-commit: 0d4b473ee54d2376f4f71efd864aa0e16822d4ba
Part-of: odoo/odoo#118710
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this commit, messages can be pinned on a channel and
chat conversation. There's a new menu listing all pinned
messages on a conversation, and we can jump to these messages
in the current conversation.
As this feature incentives to see older messages, this commit
also adds a "Jump to Present" button when looking at old messages.
closesodoo/odoo#116666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Adapt code of message fetch so that fetching of
(needaction) messages are controlled in a way to
keep continuous sequence of messages at all time.
This code design solves the "holes" problem in a message
list by not allowing holes. This fixes many scenario that
generated these holes, resulting in unfetchable messages.
Example of such a scenario:
- post 40 messages
- post a new message that is reply of the oldest message
- page reload and scroll up until load more
=> 10 messages are missing in-between replied message and
following message (that should have been 11 messages apart)
This code also prepares for allowing jumps in a conversation.
Part-of: odoo/odoo#116666
"Order by" makes the query really slow.
On a database with 1000000 partner and 10000 user, this query goes from 5.5s to
600ms. Once cached by Pgsql it goes down below 100ms.
task-2982401
closesodoo/odoo#118198
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
While we run cron `Data Merge: Find Duplicate Records` an issue raises because
`data_merge.model` has no method `_message_compute_subject`. Indeed it is
possible to notify on non-thread models but that method is a thread-only
method.
In this commit, we only call `_message_compute_subject` when it's available
in model.
sentry-3947126655
Task-3254379
Part-of: odoo/odoo#117763
Before this commit, the portal user get a Access Error.
After this commit, the portal user see the chatter without error.
The code works with reaction browsed in sudo, but since we use a ior
with a record not in sudo, we loose the sudo flag and so the right for
portal user to read it.
```py
x = record.sudo()
y = record
x |= y -> (x, y) in sudo
y |= x -> (x, y) not in sudo
```
How to reproduce ?
Assign lead to a portal user
Post a message with another user like demo on the lead
Add reaction with the admin user
Open the opportunity on the portal with portal user
-> access error
opw-3215507
closesodoo/odoo#117313
X-original-commit: 2bde53541b7a0171c7d1b89e0e412d624f5eab37
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Currently there is no way of knowing who changed the address
of a partner. This field is of high importance and should be
tracked to be able to follow who is editing it.
As addresses are represented with a bunch of fields, tracking
them individually would result in weird-looking tracking
messages with each value stacked on top of the other.
To avoid this, we take advantage of the fact that tracking can
be used on non-stored compute fields to log any change as a
change over the full address.
The full address is derived from the contact_address field to
take advantage of the existing regional formatting of addresses.
It is however modified to replace return to lines with commas to
accomodate the formatting of tracking messages in the front-end.
task-3165293
closesodoo/odoo#114695
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Use case
--------
If the a user has partner_share set to NULL not to 'false'
he will not receive any notification
The orm consider False and NULL value as False for boolean field,
the query that fetch the recipient data should have a consistent
behavior
closesodoo/odoo#117083
X-original-commit: a50fbd1f9404fd05eb576474eb3d10c94d37aa52
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`PartnerRoot` is a confusing name for what is in fact what everyone call `odoobot`
closesodoo/odoo#116823
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Steps to reproduce:
- Install l10n_mx modules
- Switch to MX company
- Create invoice and confirm it
- Send it to PAC in test environment (Process Now button)
- Click Send & Print button
Issue:
- XML Preview does not display, only shows the file name in the top right corner of the chatter.
Cause:
In l10n_mx_edi, when posting the invoice, the only attachment available is the xml sent to the government in `_message_set_main_attachment_id`.
Therefore the xml is set as the main attachment.
When clicking on "Send and Print", the pdf is generated but the main attachment is still the xml
Solution:
Redefine the main attachment everytime the the main attachment is an xml
Note:
- octet-stream have also been filtered out
opw-3085934
closesodoo/odoo#116784
X-original-commit: 48e6e81a47f5371f5985d135e56f39f445eb2854
Related: odoo/enterprise#38861
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If applied, this commit will solve the keyError for _invalidate_documents.
Before this commit:
============================================
KeyError 'rating' or 'False' occurs when a user tries to send a message and
_invalidate_documents() takes the parameter model equal to 'rating' or 'False'.
but the model 'rating' is not available in the database and It will be accessed
by the self.pool[model].
After this commit:
============================================
Solved the issue when the model 'rating' is not available or the model is 'False'
while sending a message.
sentry - 3956327451
closesodoo/odoo#116302
X-original-commit: 5becbca6531d5829bee262a5c1b64ae5e0917f8e
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since [1], the `temporary_id` of a message is passed to the
`message_post` route in order to renconciliate the temporary
message on the client side and the real message created by the
server.
This led to crashes when sending message on the chatter because
this parameter was not allowed as a `_notify_thread` parameter.
Since this parameter is highly specific and isn't linked to any
business/model code, this parameter is now passed via the context
thus solving this issue.
[1]: https://github.com/odoo/odoo/pull/116085closesodoo/odoo#116333
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit removes the "new message" separator when posting a
message on a channel.
At the same time, this commit solves an issue that caused messages
to flicker when the message came from the bus before the answer of
the rpc.
In order to do so:
- messages are marked as read immediately after
`message_post` for the member of user that posted it.
- a temporary id is passed to `message_post` in order
to reconcialiate temporary/server messages.
task-3232911
closesodoo/odoo#116085
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Previously:
The displaying of the technical menu email would be cut
if you had a zoom of > than 100% on your browser
Currently:
It allows to see the whole content of the message without scrolling.
closesodoo/odoo#116124
X-original-commit: 5055b374c3bac0126f441dad61afd7e0b68b1370
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>
OSError: cannot read from timed out object while evaluating a
"model._fetch_mails()", it occurs because when we try to quit a POP server
of incoming mail using the "pop_server.quit()" method, sometimes it is not
able to reach the remote server to quit the pop server, so it throws an OSError.
We added the try block for POP and IMAP.
if it fails then we display the os error.
sentry-3932133536
closesodoo/odoo#116004
X-original-commit: 0c30529cc9256c0b2483c2fcbbc599b87c1f8577
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Add back the 'sudo()' on batch mail unlinking.
Sudo is necessary to delete user notifications on auto-delete.
Which makes sense as the recipient would have an email for it anyway.
The sudo was there as far back as:
c5c369355d
Then transfered in this change:
036a739b62
And removed in the recent optimization here:
e38bfd25df1bb25e7e5695b536052d5a0c85c5c4
task-3225207
closesodoo/odoo#115956
X-original-commit: 93a28f17024511e30d3c70eb847c361ca87e0ffe
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- select a different company from the main one
- under settings/discuss enable External Email Servers
- set up an alias domain
- create an SO and send it by email
(you can catch the sent email using mailhog)
- reply to that email
(you can use the support-tools[1] and set In-Reply-To: "previous message_id")
Bug:
the reply_to field of incoming message defaults to the first company
Fix:
set the reply_to field to the company asociated to the record
(there's already a fallback to self.env.company in
"_notify_get_reply_to_formatted_email")
opw-3060214
[1]: https://github.com/odoo/support-tools/tree/master/scripts/mailclosesodoo/odoo#115090
X-original-commit: d86e57404d540762fa51afeabeddd3a0fc45d4d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a mail.activity record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment: layout translated based on template 'lang' field definition
or fallback on current user's lang;
* mailing: no layout supported;
PURPOSE
Translate layout into recipient's lang when available, instead of either
current user or template defined lang. As it is contextual better translate
it to the end user lang.
SPECIFICATIONS
Move recipients and email layout rendering into a method returning an iterator.
That way a list of recipient groups (as given by '_notify_get_recipients') can
be split into sub-groups, with each having its own rendering values for
email notifications.
Do a split / recipient lang. It is already fetched when notifying messages
as part of '_get_recipient_data' returned values. We now return recipients
groups per lang and per usage type (user, portal, customer, ...). Rendering
values are computed for each group as several values depend on the lang (
actions, notification buttons, global layout, ...).
Layouts when posting are dependent on recipient lang, and not on current user
anymore. Template lang that forced the content lang is now used only as a
fallback when recipient have no lang.
SUMMARY
When a user in Spanish, posts using a template specifying the lang of the
customer on a record whose customer is in French, with a follower being
in English
* content will be translated following template choice, aka french;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
When a user in Spanish, posts some custome content on a record whose customer
is in French, with a follower being in English
* content is whatever the user wrote;
* layouting for the french customer will be in french, layouting for the
english customer is in english, while the core content is always the
same and in french;
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Task-3186426 (Mail: Support notification layout in template / email composer)
Part-of: odoo/odoo#106177
Co-authored-by: Julien Banken <jbn@odoo.com>
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
PURPOSE
Take translations from template when composer content is the same as the
template one to benefits from their translations.
SPECIFICATIONS
When rendering some fields fetching translations can be complicated. Indeed
when using a template the translation is stored on template model while the
rendering is done on composer model. Translations are therefore not fetched
as fields of the composer record itself are not translated. It is a transient
record, not something people translate manually like templates.
As translations are not stored in a table anymore we can't really fetch
translations, except from using directly the template field. In this commit
we therefore do the rendering based on template value instead of composer
value when they are considered as equal and if a translation is asked either
through 'compute_lang' of 'force_lang'. This allows to fetch template
translations instead of composer translations.
If the composer content has been modified compared to the template we keep
the old behavior, which means probably no translations. Let us hope editor
does not mess too much with html content.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
Concerning layout (to be fixed in next commits):
* layout is partly translated into spanish (customer's lang) if coming from
form view, otherwise is in english (current user's lang);
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
When rendering content, options can be given to trigger some behavior
like post processing (links shortening) or comments to preserve in html
(for email reader specific commands).
In this commit we make an allowed list of options. This eases debugging
or finding wrong calls, outdated options, ...
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose of this commit is to improve behavior or mail.compose.mixin when
removing the template. It now voids the value to avoid having half baked
definition on composers.
Summary of behavior
* when choosing a template: existing (non void) values override any value
in the composer mixin;
* when removing a template: reset values;
* when going from templateA to templateB: works like choosing a template
which means only non void values are taken. This may lead to half-baked
content but trying to remove old template content based on _origin and
content comparisons would be complicated for few added value;
This makes the 'mail.compose.mixin' behaves like 'mail.compose.message'
wizard which was recently updated at odoo/odoo#107356.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#106177
svs-odoo