Currently, the template headers all have the same default behavior, you
cannot define different default behaviors for header A and header B
(e.g. have header A appear over the content and header B fixed).
This commit allows to specify other behaviors than the default ones for
each header template. It should be noted that, as it currently stands,
most options trigger a reload of the page, which prevents simpler
solutions like using `data-trigger` attributes to tie some options to
the header selection.
Specifically, this commit:
- defines a header visibility for each header with `data-trigger`. This
is actually the only option of the 3 concerned by this commit that could
be handled that way, for the aforementioned reasons. Only the visibility
of the `header_rounded_box` template is actually modified, but to allow
switching back and forth between the different templates and still have
the intended Odoo experience, a trigger is specified for each header
choice (the other ones having the default visibility).
- applies the "pills" link style for the `header_rounded_box` template
and introduces a `customizeWebsiteVariables` public method to do so.
This method, called through the `data-customize-website-variables`
attribute, allows to specify additional variables that should be
modified by selecting the option. It is as of now only used in that
specific case, but could be used with a number of other options which
are defined in a similar way, such as the scroll effect, alignment,
font, logo height...
- uses the default link style to apply it to each template by default
through the use of `data-default-variables`. This is needed (1) to make
sure that the `header_stretch` template can never have another style
than the default one, as the option is hidden when it is selected, and
(2) to go back to the default behavior when switching between headers.
Both `data-customize-website-variables` and `data-default-variables` use
the same syntax: a list of `variable: value` separated by a comma.
e.g. `header-links-style: pills, header-scroll-effect: fixed`
- removes the "Round corners" option field and border-radius for headers
sales_one, sales_two, sales_three and sales_four, because the option
does not play well with their layouts.
task-3474743
Part-of: odoo/odoo#119650
Following the redesign of website template headers, this commit
introduces a new class `.o_header_hide_on_scroll` to hide some part of
the header when scrolling.
task-3474743
Part-of: odoo/odoo#119650
Following the redesign of website template headers, this commit applies
a few fixes and modifications to the behavior:
- It separates some elements' options into their own option sections:
brand logo, language picker, searchbar.
- It disables interactive elements in the header (search modal, language
dropdown, logout button) while in edit mode.
- It solves the following bugs introduced by the headers redesign:
- Displaying the language selector with an inline style and flags
only is working.
- Social links are now unmovable and unremovable (other than by
clicking on the "Show/hide social links" expressly made for it), as
their place in the templates is fixed, as allowing the snippet to be
moved caused several tracebacks, and as removing it through the
options and trying to show it again caused a server error.
- The CTA button is made unremovable (other than clicking on the
"show/hide button" expressly made for it) for the same reasons.
- It was possible to write in spaces where it shouldn't have been
(search icon, mobile menu closing icon): they are made not editable.
task-3474743
Part-of: odoo/odoo#119650
Prior to this commit, the dropdown of the search bar which was displayed
in a navbar had a static position when the viewport was below lg.
This dropdown pushed the navigation down instead of being in front of
it, creating a layout issue in the offcanvas menu.
To fix this, this commit forces the `dropdown_menu` of the search bar to
be in absolute position.
task-3060986
Part-of: odoo/odoo#119650
Prior to this commit the id used for the main navigation wasn't
descriptive enough.
This commit fixes this issue.
task-3060986
Part-of: odoo/odoo#119650
Prior to this commit, dropdown menus floated in offcanvas menus. This
can create an UX issue on mobile when you want to click/tap on a
link that is behind the open dropdown menu.
To fix that, this commit removes the floating style and lets the
dropdown menu extend below the parent button.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
This commit allows the user to show and hide the menu items they want
using the web editor.
task-3060986
Part-of: odoo/odoo#119650
Prior to this commit, icons in the user dropdown were not visible when
we applied a dark background color on the header.
In fact, when we use a dark background, it applies the "nav-dark" style
and turns the "text-muted" in a light gray which is not visible on white
background.
This commit fixes this issue by using the primary color instead of the
muted gray.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
This commit removes the following templates:
- template_header_image
- template_header_hamburger_full
- template_header_magazine
New templates were added by previous commits. Those old 3 do not have
an equivalent anymore and are simply removed.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_three" header will however
be the closest one to the "contact". A related upgrade script will be
made to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_two" header will however be
the closest one to the "slogan". A related upgrade script will be made
to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "search" header will however be
the closest one to the "centered_logo". A related upgrade script will be
made to threat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
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
Robin Lejeune (role)