This commit fixes the structures of some existing elements (language
selector, etc) and introduces new ones which will be possible to toggle
in each new header templates in following commits.
Note: the fixes may need to be backported in the future somehow.
Note 2: after this commit, some of those elements can appear broken.
This is because they are meant to be used in the new headers templates
in following commits.
task-3060986
Part-of: odoo/odoo#119650
Co-authored-by: Robin Lejeune (role) <role@odoo.com>
*: website_sale, website_sale_wishlist
This commit adds a new header template displayed on mobile screens.
It also introduces the Mobile Alignment feature, allowing the user to
adapt the Navbar alignment to mobile screens. It will replace the
previous "off-canvas" feature also available on desktop. This commit
removes that old feature but the new mobile menu will only be enabled
in each template in next commits.
task-3060986
Part-of: odoo/odoo#119650
*: website_livechat, website_sale, website_sale_wishlist
This commit adapts some templates and tests JS to prepare for the new
headers in the next commits.
task-3060986
Part-of: odoo/odoo#119650
Prior to this, there was no way of knowing when a new device logged
into your personnal account.
Adding the new version of the authenticate function, user's will now
automaticly receive a mail containing informations on a new connection
made to their account. This system uses a mail template sent
automaticly on a new connection if the user has activated 2FA and if
his device his not in the trusted devices of his account.
task-3191567
closesodoo/odoo#115362
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previous commit(s) did improve the preview of snippets when dragged and
dropped but also the `t-snippet-call` capability of some snippets.
Part of that improvement was to add snippet `onBuilt` JS output in the
snippet XML definition directly.
For google and facebook snippets, it means firing a request to those
websites when entering edit mode.
It's not that bad (considering the trade-off of the preview and
t-snippet-call), but will need to be re-discussed later post freeze to
find a better way to not fire those requests ideally when the snippet
is called in the right panel (but would need the preview to still work).
For the meantime, this request seems to be making a test fail
(`test_01_menu_hierarchies`) due to the gmap API call being returned
after the test has been marked as successful.
Before investigating further, this commit just prevent the iframe to
show up when in test mode so we can merge this work which is needed for
tomorrow freeze.
closesodoo/odoo#138748
Related: odoo/design-themes#726
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, some snippets did not have any or complete preview
when dragging them over a dropzone.
This commit covers `s_website_form`, `s_countdown`, `s_map` and
`o_facebook_page`.
Some elements with class `s_preview` are added to the template. These
elements are removed when the snippet is dropped.
Also, the class o_colored_level was added to snippets so that the
previews matches the snippet dropped.
For "New page templates", an `s_keep_preview` class can be added on a
parent element of an `s_preview` to prevent its removal when creating
the page - thereby making the snippet ready as if is had been dropped
into the page.
Note: `s_chart` and the "dynamic snippet" and its variants are not
covered in this commit.
task-3555325 (was task-2431469)
Part-of: odoo/odoo#138748
Co-authored-by: Benoit Socias <bso@odoo.com>
In [1] when the "New page from template" feature was added,
`background-image: none` was removed from many blocks to avoid having to
handle it when adding an image.
That situation actually never arised, making those removals useless.
This commit removes those attribute removals.
The only impact this has it that it fixes the `s_call_to_action` styles
in `theme_notes` by restoring their images. The `<attribute remove=...>`
actually did separately remove `background-image` and `none`, corrupting
the exiting style.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
task-3555325
Part-of: odoo/odoo#138748
In [1] when the "New page from template" feature was introduced, when
obtaining the CSS of the target website a Promise was returned which was
resolved in an asynchronous executor after obtaining a server response.
This commit relies on resolving a Deferred promise instead.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
task-3555325
Part-of: odoo/odoo#138748
In [1] a mechanism was introduced to prevent the "New page" dialog from
being opened several times.
That problem occurred at a point during development when the loading of
the templates was delaying the display of the dialog, giving time to the
used to trigger again the action that opened the dialog. Now that the
dialog is actually opening right away to give access to the "Blank Page"
pseudo template, the situation cannot occur anymore.
To simplify the code, this commit removes that mechanism which is now
useless.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
task-3555325
Part-of: odoo/odoo#138748
Before this commit, the "Table of Content" snippet only got its
navigation part rendered once the block was dropped.
In [1] when the "New page from template" feature was introduced, a
default pre-rendered content was introduced so that the "Table of
Content" snippet was properly rendered in the template previews where it
was used.
This commit moves this pre-rendered content from [1] into the base
definition of the snippet itself.
There is no collision problem regarding the default ids that are
included because the dynamic content is re-generated when the block is
dropped and whenever the headers texts are changed.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7#diff-bee4662b672e30dbfb9778f8747fee45698d9b8d16282d8f80066d8a30137928R35-R50
task-3555325
Part-of: odoo/odoo#138748
Before this commit, `invisible` attribute is used for the list view
to hide the field inside the list view but that invisible does not
hide the column.
This commit replaces `invisible` attribute by `column_invisible`
to completely hides the fields in the list as it was expected.
task-3542388
closesodoo/odoo#137820
Related: odoo/enterprise#48523
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the project of the timesheet changed, the
task_id of the timesheet is not unset and so it could have some
inconsistency.
This commit ensures the task linked to the timesheet has the same
project than the one set on the timesheet, otherwise the task_id is
unset.
part of task-2276015
task-3542388
Part-of: odoo/odoo#137820
New fa-bell icon to manage notifications according to that channel only
Options:
Mute (+choose time period):
No longer see the unread status: the bold text disappears and the channel name fades out.
As if you are not a channel member anymore.
Receive messages but without sound + only need action counter (grayed).
Add a crossed-out bell icon next to the channel or user name to indicate that the channel is muted
All messages: all messages sound + need action counter
@Mentions: only mention sounds + need action counter
Nothing (Discord-like): No sound + need action counter
By default: all messages
task-3328665
closesodoo/odoo#136405
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
If you assing a different payment account per payment method line
corresponding to the same journal (but different payment methods),
The method that returns the possible liquidity accounts returns a tuple
instead of a recordset, and the comparison is done with the operator
`in`, so if any of the elements of the tuple is a recordset of more
than one record, the match is not happening, which may be the case for
`self.journal_id.inbound_payment_method_line_ids.payment_account_id` or
`self.journal_id.outbound_payment_method_line_ids.payment_account_id`.
The solution is to return a recordset instead.
TT43014
closesodoo/odoo#139656
X-original-commit: 56279a17e52592fd19a5b0df6dd2669a7af6ab24
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if all reactions are deleted from reactions menu, the menu remains open. This commit force it close in case of having no reactions.
closesodoo/odoo#139632
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When the debug manager was migrated to OWL on ce559992, both `title`
and `aria-label` attributes were removed from the button that opens the
developer tools. However, the `aria-label` is actually required, because
such button doesn't contain any text, just the bug icon.
This commit restores (only) the `aria-label`text.
closesodoo/odoo#139630
X-original-commit: aefeb337f132d43f6ee3d5a9fc5bf4b6ef0af454
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Before, a receipt was automatically generated in the mobile self order
and the confirmation screen would glitch when it was generated.
Now this receipt is only generated in kiosk mode and the confirmation
screen no longer glitches due to a hidden overflow.
closesodoo/odoo#139625
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit, when using a livechat chatbot from visitor
and selecting a chatbot option, there was the following traceback:
```
UncaughtPromiseError > SyntaxError
Uncaught Promise > JSON Parse error: Unterminated string
SyntaxError: JSON Parse error: Unterminated string
parse@[native code]
updateSession
```
This happens because the session cookie had incorrect format for its
content. This was caused by a history prop whose content had the
character "→". When setting the cookie, the stringified object is
only partially inserted until this "→", which made the content
non-JSON parseable as the string is incomplete.
This commit fixes the issue by replacing all occurrences of the
character "→" by a whitespace, so that the setting of the cookie
works and insert the whole stringified object as intended.
Note that this "→" is used for data that is not used in the context
of livechat chatbot for the visitor, therefore this alteration of
the content has functionally no effect.
opw-3527969
closesodoo/odoo#139606
X-original-commit: 64efe60f92679767af769125ce7515ca3fff8c49
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since commit e17c2135cb24aa600eeff9426b93665537a33d00, if an error is thrown
during the "save" of X2ManyFieldDialog, the buttons are enabled().
So the patch on X2ManyFieldDialog in question_page_one2many_field.js is
no longer useful. So we're going to remove it.
closesodoo/odoo#139550
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit escape was needed to use a Markup object as a
parameter, hence loosing the fallback mechanism in translations
>>> escape(_("Order %s has been confirmed")) % Markup("<a>%s</a>") % order.name
Markup("Order <a>SO42</a> has been confirmed")
Now it is possible to explictly give a Markup object to the gettext call
>>> _("Order %s has been confirmed", Markup("<a>%s</a>") % order.name)
Markup("Order <a>SO42</a> has been confirmed")
Part-of: odoo/odoo#139316
RATIONALE
Currently only one alias domain is possible when using Odoo. Even if several
outgoing and/or incoming email servers can be used, all "reply-to" email
addresses belong to the same global email domain. Moreover incoming emails
cannot be cleanly limited or checked against a company as we accept all
incoming emails sent to aliases to ease notably email forwarding.
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Allow companies sharing a database to handle their mailing flow independently
e.g if a travel agency group uses Odoo to handle its business. Each agency is
a company with their mail domains and servers like 'info@travel.namur.example.com'
'info@travel.liege.example.com'.
ALIAS DOMAINS
Add a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from (filter) are also moved on this model, allowing
an higher level default from computation for mail servers when having knowledge
of alias domain environment.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
ALIASES
Add 'mail.alias.domain' information on alias model. Aliases do not use global
configuration parameters anymore. Instead they are linked to an alias domain
e.g. 'sales' linked to 'mycompany.com' alias domain: 'sales@mycompany.com'.
It is now considered as a different alias compared to 'sales@mycompany.in'
which has the same alias_name but a different alias domain.
Constraints and checks are added, as
* uniqueness of aliases is now checked inside a given domain;
* an alias name must not clash with its domain bounce or catchall;
* a combination of (alias_name, alias_domain_id) must be unique;
Now that alias domains are multiple and can be linked to companies it is
easy to end up with configuration where an alias is using a domain of
CompanyA while the owner and/or target record belongs to CompanyB. We
want to avoid that situation and strengthen company separation.
When changing alias domain of an alias check that it is not used in another
company than the one define on
* the owner record (using owner fields like the 'project.project' for
'project.task' creating aliases);
* the target record (using update fields like the 'mail.group' for group
aliases that routes emails to a specific group);
If the new alias domain is linked to a company that is different from the
company of any related record, raise an error as it could lead to invalid
multi-company setup and record creation.
If the new alias domain is different from the company domain but is not
used in any company it is a valid configuration. It is just flexibility
offered by multi-domains aliases.
MAIL GATEWAY
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
EMAIL FLOWS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
MAIL.MAIL AND OUTGOING EMAILS
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
USAGE: CONFIGURATION
Update settings to configure your company's current alias domain instead
of the global 'alias.catchall.domain' configuration parameter. As domain
configuration is globally done per company, this is now a related on the
company. Advanced configuration and management can still be done manually
in settings.
USAGE: SEARCH
Currently alias search is done only on 'alias_name' field. Now that alias
domains can be multiple we have to be able to search on complete alias
email definition e.g. when checking destination aliases of incoming emails
in mail gateway.
We add a new 'alias_full_name' field that is computed based on alias_name
and alias_domain_id.name. It is stored so that search is possible on it.
Allow to search on 'alias_full_name' from the 'mail.alias.mixin(.optional)'
by making 'alias_email' field searchable, based on 'alias_full_name'.
USAGE: APPS
Update fields used in form views. Use 'alias_domain_id' instead of domain
that is now simply a related on 'alias_domain_id.name'. To ease UI we add
a placeholder on this field as it is now writable e.g. in multi domains
environment. Avoid unwanted configuration change by making it generally
no_open / no_create_edit.
NOTE
Query counters are not at their real value, they were not updated to the lowest
count because of the merge frenzy that might have an impact on those.
LINKS
This merge is done on top of several preliminary work, notably
* odoo/odoo#130750 (move ICP to mail, prepare mail server code)
* odoo/odoo#130632 + odoo/enterprise#45118 (alias cleanup)
* odoo/odoo#130468 + odoo/enterprise#45036 (mail/phone tools cleanup)
* odoo/odoo#138213 + odoo/enterrpise#48692 (remove 'alias_user_id')
* odoo/odoo#138202 (email_from check at email send)
Test suite preparation
* odoo/odoo#130768 + odoo/enterprise#45204 (test suite preparation)
* odoo/odoo#131492
* odoo/odoo#135055 + odoo/enterprise#47243
* odoo/odoo#136102 (mail server test preparation)
* odoo/odoo#137895 (test tours cleaning)
* odoo/odoo#138202 (test suite clean inside email_from check)
Task-36879 (Mail: Support Multi Domains Aliases)
closesodoo/odoo#76734
Related: odoo/enterprise#20983
Related: odoo/upgrade#2846
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Update counters after all changes. Notably storage of environment variables
(company, alias domain) during mail creation and sending process as well as
computing values depending on alias domain (e.g. reply_to, return-path) lead
to some additional queries to read companies and their alias domains.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are used in Odoo codebase there is no usage anymore
for the old config parameters. So long and thanks for all the fish !
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Update fields used in form views. Use 'alias_domain_id' instead of domain
that is now simply a related on 'alias_domain_id.name'. To ease UI we add
a placeholder on this field as it is now writable e.g. in multi domains
environment. Avoid unwanted configuration change by making it generally
no_open / no_create_edit.
In project, remove an unnecessary field adding complexity for few real use
case now that aliases are more open to configuration.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Update settings to configure your company's current alias domain instead
of the global 'alias.catchall.domain' configuration parameter. As domain
configuration is globally done per company, this is now a related on the
company. Advanced configuration and management can still be done manually
in settings.
Field 'external_email_server_default' triggering display of mail configuration
is moved to mail. It is defined in 'base_setup' but used only in mail hence
moving the field to be coherent.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Currently alias search is done only on 'alias_name' field. Now that alias
domains can be multiple we have to be able to search on complete alias
email definition e.g. when checking destination aliases of incoming emails
in mail gateway.
We add a new 'alias_full_name' field that is computed based on alias_name
and alias_domain_id.name. It is stored so that search is possible on it.
Allow to search on 'alias_full_name' from the 'mail.alias.mixin(.optional)'
by making 'alias_email' field searchable, based on 'alias_full_name'.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are multiple and can be linked to companies it is
easy to end up with configuration where an alias is using a domain of
CompanyA while the owner and/or target record belongs to CompanyB. We
want to avoid that situation and strengthen company separation.
When changing alias domain of an alias check that it is not used in another
company than the one define on
* the owner record (using owner fields like the 'project.project' for
'project.task' creating aliases);
* the target record (using update fields like the 'mail.group' for group
aliases that routes emails to a specific group);
If the new alias domain is linked to a company that is different from the
company of any related record, raise an error as it could lead to invalid
multi-company setup and record creation.
If the new alias domain is different from the company domain but is not
used in any company it is a valid configuration. It is just flexibility
offered by multi-domains aliases.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
As 'alias_domain' is now dynamic and not based on a configuration parameter
it makes sense to be able to change it when having several alias domain.
We now allow writing on 'alias_domain_id' in 'mail.alias.mixin(.optional)'.
Users may now change the alias domain of the alias coming with the mixin
when they have write access on the record.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add 'mail.alias.domain' information on alias model. Aliases do not use global
configuration parameters anymore. Instead they are linked to an alias domain
e.g. 'sales' linked to 'mycompany.com' alias domain: 'sales@mycompany.com'.
It is now considered as a different alias compared to 'sales@mycompany.in'
which has the same alias_name but a different alias domain.
Constraints and checks are added, as
* uniqueness of aliases is now checked inside a given domain;
* an alias name must not clash with its domain bounce or catchall;
* a combination of (alias_name, alias_domain_id) must be unique;
Crm multi-company environment is also updated to match the new alias domain
behavior.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from is also moved on this model, allowing an higher
level default from computation for mail servers when having knowledge of
alias domain environment. Filtering configuration based on default_from_filter
is kept as an ICP as it is mainly used for odoo-bin with smtp-host.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
Currently only base modeling and computation is done. Their usage is about to
be gradually added in mail stack.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Composer tests now use the multi-company enabled model by default, allowing to
test company-dependent behavior. This has no impact on current tests, as there
is no company-dependent fields on composer model, and all tests are anyway
run into the main company (except multi-company specific tests, suffixed
by '_mc' generally).
We therefore also add some multi-company oriented tests to check notably
return-path or environment companies in various scenarios. Go until the SMTP
generation to test mail server choice, smtp_from and filtering, notifications
email.
Followup of odoo/odoo#136318 and odoo/odoo@3ffa1a0611 notably.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
This may have an impact when trying to find an outgoing mail server based
on from and filter, as first match wins when checking matching filter on a
bunch of mail servers.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Due to current implementation of mocks context is lost when accessing methods
'connect' and '_find_mail_server' of IrMailServer. Indeed self is replaced by
an instance of IrMailServer and code relying on context could not be called as
planned.
This commit aims at doing a custom mock so that we can correctly rely on self
and context in those methods. This is necessary for incoming changes in mail
notably to allow testing SMTP feature in multi domains environment.
Logged information when having failed SMTP check is improved: we now also
log found From in order to ease debugging failing tests due to invalid from.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
When composer runs in 'rendering' mode, it is often based on a mail.template
record that gives information about recipients. When having no template
default recipients are added to be sure to contact 'intended people'.
When rewriting code in 16.2, support of batch-comment was added in addition to
mass mailing. Result is that now default recipients are also computed when
posting in batch. However when posting we consider recipients are already set
on records using followers. Adding default recipients to avoid dummy emails
is present mainly for the mass mailing mode.
Followup of odoo/odoo#107356
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Before this commit, live chat would fail for guest portal. In this
scenario, there is no guest token. Before this commit, the guest
token was sent anyway with `null` as value which caused a crash.
closesodoo/odoo#139585
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to reproduce:
-------------------
- install `account` module;
- create an employee;
- add a bank account;
- add a related user and save;
- remove the user and save;
Issue:
------
A traceback occurs.
Cause:
------
We synchronize the `partner_id` of the `bank_account`
with the `work_contact_id`.
If the latter is `False`, this triggers an error.
Solution:
---------
Do not trigger the logic that updates the `partner_id` of
the `bank_account` if the value is `False`.
This keeps the logic that the `partner_id` field
in the `res.partner.bank` model is required.
opw-3558983
closesodoo/odoo#139570
X-original-commit: c19574e26d8814a745152489eb16915f13b2a6c0
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Brieuc-brd