odoo/odoo#76734

Created by Marketing, Thibault Delavallee (tde)

label

odoo-dev:master-alias-cid-tde

head

38a26b940dc911f2bcc7791aa0f30bf24f2d5126

merged

3 years ago by Marketing, Thibault Delavallee (tde)

[MERGE] mail, various: support multi domains aliases

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
* #130750 (move ICP to mail, prepare mail server code)
* #130632 + odoo/enterprise#45118 (alias cleanup)
* #130468 + odoo/enterprise#45036 (mail/phone tools cleanup)
* #138213 + odoo/enterrpise#48692 (remove 'alias_user_id')
* #138202 (email_from check at email send)

Test suite preparation
* #130768 + odoo/enterprise#45204 (test suite preparation)
* #131492
* #135055 + odoo/enterprise#47243
* #136102 (mail server test preparation)
* #137895 (test tours cleaning)
* #138202 (test suite clean inside email_from check)

task-36879 (Mail: Support Multi Domains Aliases)