Odoo's Mergebot
a14dc16a60
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) closes odoo/odoo#76734 Related: odoo/enterprise#20983 Related: odoo/upgrade#2846 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials