Followup of odoo/odoo@d6d6bee087 : test was not written to be independent
from demo data.
Also update other tour that fails in no-demo mode as portal user has not enough
address value set to continue the tour, compared to demo mode.
Task-3871775
Runbot-56554
Runbot-56553
Runbot-61488
Runbot-58213
closesodoo/odoo#162021
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
date_open should not be set when there is no user_id set. Let us be coherent
so that we can see the effect of assigning users that updates the date_open
field.
Task-3515225
X-original-commit: 3720e5aefd7bf9971d0d7b6fc93fc90c1eeecad3
Part-of: odoo/odoo#161918
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
X-original-commit: a3dbe23b83e7aae108ff72737c69c783e059f603
Part-of: odoo/odoo#161918
Currently, if we create a new event mail "after each registration" to be send
directly, the next time we confirm a registration it tries to send the
communication to all registrations that are not yet contacted. Indeed
the first new registration triggers the scheduler which runs on all
pending registrations. This may potentially break the transaction or
at least make it extra slow.
Now, we send the mail only to the new registrations (created after the
event mail). Old registrations will be contacted via the CRON instead.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
Co-authored-by: Stéphane Debauche <std@odoo.com>
Various registration side updates depends on its state: notably communication
schedulers and lead rules management.
However event_sale changes the 'state' field from a classic selection field
to a computed one, introducing links with sale order and sale order lines
as well as payment state computation.
Currently code leads to a double update of state when creating a new
registration, which causes communication scheduler to be called twice and
create additional queries. This commit tries to avoid this by updating value
of state only once, instead of setting everything to draft then updating to
another value afterwards. This avoids notably schedulers to be triggered
or called twice in the same transaction.
Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
This commit introduces a new configuration parameter 'event.event_mail_async'
forcing registrations-based communication to be asynchronous. Instead of
directly sending communication it triggers the cron to be run as soon as
possible.
When having large volume of registrations, and especially concurrent
registrations it saves a DB to avoid generating tickets and preparing emails
synchronously to the registration creation.
Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155777
She disappeared between 15.2 and 16.0 but seems she is still alive. Commit
odoo/odoo@88483a6 does not seem to have been forward ported after 16.0.
closesodoo/odoo#151920
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When adding alias domain in v17 support of configuration parameter
was dropped. We moved from singleton configuration to multi domains
using real models.
This means most of mail support lies in mail while part of it was in base
beforehand. In some cases we want to let people do some basic
configuration using base module then install mail which could migrate
this ICP based configuration into new models. This is notably the case
with odoo.sh where mail is not always automatically installed.
Use case is: install base, do some configuration using ICP allowing notably
to setup website / server domains, main mail configuration, ... then let
people install modules on top of that configuration which generally
installs mail. With this change existing ir.config_parameters matching
pre v17 names are now used to bootstrap alias domain table at mail module
initialization.
Task-3789584
closesodoo/odoo#156654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make them easier to improve and modify
* use a dedicated setup (allowing to add specific unit tests on test data);
* move initial asserts into its own unit test (to keep other tests shorter);
* use available mocks for freezetime and sql.now;
Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
They fail at least in local as we don't patch env.cr.now. Forcing 'create_date'
is possible, but we now have a tool 'mock_datetime_and_now' mocking both
the cursor 'now' and use freeze_time for other datetime mock. It makes tests
more reproducible and less ORM-dependent when trying to manipulate creation
date.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
Ease understanding the purpose of main fields on alias domains. Set bounce,
catchall and default_from available in debug mode as those are advanced
configuration bits that should be displayed (and modified) with care.
Add tooltips on fields to ease understanding the field usage.
Task-3696224
closesodoo/odoo#150401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Now that code is fixed there are more access to channel members and partners
to send them push notifications notably. Some tests are crashing when public
users access channel pages and perform actions that send push notifications.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@1955c55f86
Sending notifications can be delayed by giving 'scheduled_date' as parameter
for notification process. This is used notably when a process in several
steps should wait for some user input before sending notifications e.g.
rating feedback and update done in two steps.
Sending web push notifications should respect this scheduling as already
done by inbox and email notifications.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@24ebd74dc9
Recipients on a channel notification are computed twice: once using an
override of '_notify_get_recipients' that fetches information of mentioned
recipients; once in override of '_notify_by_web_push' to try to add
recipients for push notifications.
However this is not the right way to do it. Everything should be computed
in '_notify_get_recipients', setting the right 'notification_type' and then
let 'notify_by_MEAN' methods deal with their recipient input.
In this commit we now correctly compute recipients on a given channel
* mentioned partners;
* unmuted members on chat channels (push);
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@f312762c6a
'_notify_thread' calls '_notify_thread_by_web_push'. There is therefore no
need to call it once again in discuss.channel override of '_notify_thread'.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
Part-of: odoo/odoo#150011
Backport of odoo/odoo@e3125c8389
A lot of keys are missing compared to standard '_notify_get_recipients'.
This is done in two methods that are updated to include keys defined
in 'MailFollower._get_recipient_data()' that contains the reference
structure to return.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
X-original-commit: 7a46a957764aa5ee97a0a183fa1b747de85ff8ac
Part-of: odoo/odoo#150011
Just extract some code we should otherwise copy in both mail_mobile and
mail_enterprise.
Task-3695571
Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
X-original-commit: a6b0e88d00e1dcd4abbc1e37d62d65063c6956de
Part-of: odoo/odoo#150011
Default_from on alias domain is currently managed like bounce or catchall.
We consider it is always only a left-part of an email address that should
be completed with alias domain name.
However and notably at migration default_from could contain a complete
email address. In that case better be defensive and keep the domain part
of the value.
Task-3690919
closesodoo/odoo#149887
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
'_redirect_to_record' is used notably when accessing 'mail/view' controller
used notably with email notifications ('See Document' link). In order to
try to avoid multi company issues a call to '_get_mail_redirect_suggested_company'
is performed in order to find the record's preferred company.
However it is defined on 'mail.thread' which means the redirect crashes if
invoked using a non thread record. This is quite rare but may happen with
models using a mailgateway implementation similar to 'mail.thread' without
inheriting from the mixin (see 'mail.group' model added in Odoo 16).
This limitation is present since a long time but is now more present since
odoo/odoo@f4523fcd92 .
Task-3689459
closesodoo/odoo#150309
X-original-commit: 9a366dcdb789d0f160871ee4d29a463e2641ca26
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fix various use case of HTML encoding / escaping in mail flows. Depending on
functional flow HTML entities could appear as they were not correctly
managed as valid HTML.
Notably when managing attachments in '_process_attachments_for_post' we
should return Markup-ized HTML to be sure it is considered as valid in
other post processing.
Task-3675159 (Mail: correctly escape HTML when updating content)
Task-3619348 (Mail: propagate markup flag when processing attachments)
closesodoo/odoo#148769
X-original-commit: f4bf63077d4129807e00e15b833e47623869491f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After some testing notably with WhatsApp module, it appears usage of phone
numbers could be a bit more defensive to try to accomodate with data users
entered. Notably when failing to recognize a number, we can distinguish
error and try to reformat it based on two commonly spotted errors
* missing "+" in front of a E164-like number (e.g. '32455001122');
* usage of "00" in countries where it is not really standard to use it
instead of a "+" (e.g. '0032455001122');
Those find of numbers generate a 'TOO_LONG' error from phonenumbers library.
In that case we try to reformat it just to see if we can do better with it.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@85c1306156
Part-of: odoo/odoo#146398
In this commit we add a new tool function in 'phone_validation' tooling
module. This tool 'phone_get_region_data_for_number' returns
* 'code': the region code from phonenumbers library, which is like 'BE' or
'GB' and (should) be the uppercase version of odoo country code;
* 'phone_code': the 'country_code' from phonenumbers library parsed object
which is actually the phone code of the country (might not be unique
e.g. 1 for US and CA);
* 'national_number': the 'national_number' from phonenumbers library parsed
object which is the number without the 'phone_code' prefix (e.g. for a
belgian number +32485001122 it is 485001122).
This will be used in whatsapp (enterprise) to ease finding country (and
partners) based on an input number.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@646aa8f369
Part-of: odoo/odoo#146398
Add a tool to simulate opening a mailing at trace level in addition to existing
tools to simulate a click or a bounce
Task-3506681 (MA: Test cleanup)
Prepares Task-2981581 (MA: Fix trace duplication and various issues)
X-original-commit: 1d4829e0597e4498663542381882ff810c5e42b5
Part-of: odoo/odoo#143088
Move '_create_mailing_list' as a base mass mailing tool to make it easily
usable by most mail-related test addons.
Improve '_filter_mail' tool by allowing to give an additional 'email_from'
used to filter emails produced under a mock. When having similar records
mailed several times (e.g. several mailings triggered at the same time which
may happen for marketing automation tests) it eases finding the right email
linked to a given mailing / recipient.
Improve some logs to ease debugging, notably for marketing automation.
Task-3506681 (MA: Test cleanup)
Prepares Task-2981581 (MA: Fix trace duplication and various issues)
X-original-commit: aad84dda189e13d76a87e349a7d56d84e584879c
Part-of: odoo/odoo#143088
Remove quotes when name of a formatted email is also an email, as indicated
in tests. We still get two emails being sent for a given outgoing email
when the name part is an email but that would be difficult to avoid.
Task-3566542
closesodoo/odoo#141856
X-original-commit: odoo/odoo@d3cdaa6c18
Related: odoo/enterprise#50892
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add test cases related to an issue found during mail gateway testing. When
an email_to is formatted like '"robert@notgmail.com" <robert@notgmail.com>'
the tool finds two emails. As it is used in IrMailServer it sends two emails
insted of one. This may happen notably when partners are automatically created
based on an email only in which case it is put in both name and email.
Task-3566542
X-original-commit: odoo/odoo@312323e0d9
Part-of: odoo/odoo#141856
When 'getadresses' fails at parsing some input and give us a result like
'gmail.com' (see previous commit adding test cases) we fallback on using
'email_re' which is better at finding email addresses in a global string.
We use it only in this specific case as fallback mechanism to rely on
'getadresses' when possible.
Task-3572208
X-original-commit: odoo/odoo@8e61a3b690
Part-of: odoo/odoo#141856
Add test cases related to issues found in various leads management. All those
email inputs lead to an email found being '@gmail.com' (or equivalent) which
is not a valid email.
A consequence of that behavior is that 'email_normalized' for several leads
is the same ('@gmail.com') and they are considered as being the same email
identity. They could be included in a pack of leads to merge (see 'crm').
Task-3572208
X-original-commit: odoo/odoo@7498b9a0a1
Part-of: odoo/odoo#141856
Currently both incoming and outgoing emails are using the same 'email'
message_type. However both flows are not linked in any way.
Purpose of 'message_type' is to distinguish who generated the message.
In this case incoming emails are generated by the mailgateway while outgoing
emails are generated by mailins e.g. using the composer in mailing mode.
We now distinguish outgoing emails from incoming emails by using a specific
type for outgoing emails. Addons are updated accordingly.
Default 'message_type' value when removing sms/snailmail/whatsapp is now
'comment' instead of 'email', as default value of messages should be
comment as discuss is the main source of messages.
Task-3285720
closesodoo/odoo#139814
Related: odoo/enterprise#49597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently creating a record with 'is_published' being False (aka not published)
crashes when people can't publish. However 'is_published' being False is the
default value, and create should work in both cases.
It now correctly checks that published records could effectively be published.
This allows to remove a small workaround done in eLearning.
See odoo/odoo@4086f344d8 for ref.
Only failing use case would be having
def _default_is_published(self):
return True
def _compute_can_publish(self):
for record in self:
record.can_publish = self.env.user.has_group('something')
But this would not be a really valid use case: not being able to publish
but having default publish to True makes no sense: what matters is publishing
records as it gives more visibility to records, not the flag change itself.
Followup of odoo/odoo#70291
Task-3299702
closesodoo/odoo#137900
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
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
Improve link preview code
* remove useless code indirections;
* improve performance of link creation, cleanly support batch-creation (could
lead to 98+5 URLs to the same domain creation within default 10 seconds
instead of 98+1 but we feel it's ok);
* name methods according to ORM;
* use tools for html empty;
Also cleanup link preview tests: concatenate tests when possible, improve
setup, use real-life scenarios (using 'message_post' notably), remove useless
data creation.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
There is a o2m / m2o link between mail.message and mail.shortcode. However
this link is not used: 'messages' (m2o from shortcode to message) is never
set. Anyway there is no usage of this link: shortcodes are replaced in
message body and that's it.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
'email_formatted' on 'res.company' model depends on its formatted catchall
and its underlying partner formatted email. However we do not need to
give 'partner.id.email_formatted' trigger in the compute methods as it is
not stored and thus do not need to recompute it for every change of linked
partners in DB; it is valid for the current transaction. It allows to lessen
invalidation of computed fields.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
'alias_user_id' field allows to set a user when creating records through the
mail gateway. This is however quite wrong and eases spoofing. The alias owner
is not the creator of any record, nor responsible.
Current possible ways of being owner / responsible of records created through
the mailgateway
* when you send an email to an alias: if you are recognized you are already
set as creating user and logged message author;
* it is possible to use alias_defaults notably to set fields like 'user_id'
if you want to be notified / responsible of records created through this
specific alias;
Those usages are therefore sufficient, no need to have another way to spoof
users. Moreover it is hidden in technical view of aliases, no model allows
to configure it by default. Moreover since odoo/odoo@3edf181 no default
value is given to alias_user_id as it adds more (ACLs / creator) issues than
really helping setting up mail gateway flows.
Task-3453482
Prepares Task-36879 (Mail: Multi-Domain Aliases)
closesodoo/odoo#138213
Related: odoo/upgrade#5259
Related: odoo/enterprise#48692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to try to detect and log 'email_from' invalid
values when sending emails based on outgoing 'mail.mail'. This implies
checking the returned messages when having a generic Exception when sending
the emails, as we distinguish two use cases that raise through a simple
raise: missing from and invalid from.
New failure types 'mail_from_missing' and 'mail_from_invalid' are also
added at 'mail.notification' and 'mailing.trace' level, as other failure
types.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#138202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Extract some test preparation, cleanup and improvements before gradually
adding features that impact tests.
Add tests about 'copy()' behavior in 'mail.alias.mixin' as it will be
impacted by multi-company enabled aliases.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138202
Reorganize tests, perform some renaming. Tests stay as they are to ease
comparison through versions. We notably extract formatting related tests
into their own class, allowing to keep their setup only for those tests.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
RATIONALE
Currently when an ir.model.fields is removed all tracking linked to it is
lost. Indeed field is required and has an ondelete cascade attribute set
to it. However we should keep tracking values as those made sense when
used and one could want to have access to this information.
SPECIFICATIONS
When removing fields set the field to False instead. Add a new field to
store fields information allowing to keep name, type and groups information
to allow displaying removed tracking values. Use this field only when a
field is removed to avoid duplicating field information when not necessary
and polluting the table.
Task-3499067 (Mail: keep tracking when unlinking fields)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'old_value_monetary' and 'new_value_monetary' fields on tracking model.
Float fields can be used instead as anyway what is important is the type
of value stored, not their actual purpose.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'field_desc' and 'field_type' from 'mail.tracking.value' model. Those
can be retrieved when necessary, as it is mainly used for frontend display
in Chatter.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'tracking_sequence' on tracking values in DB. Consider insertion order
should be done accordingly and display them based on ID DESC. Sequence is now
used only for order records to insert in DB. Feature is still the same (order
based on sequence) but without having to store the sequence itself. It was
never updated anyway.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Currently tracking an unsupported field type simply skips the field. As code
has been cleaned and natively support 2many fields we consider tracking should
be done only on supported fields. Otherwise people might wonder why tracking
does not work.
We now raise when the type is not supported, which is currently the case for
html fields. As they may contain lot of data it is better to think of a
specific tracking based on history / diff than logging old / new value.
When the field does not exist on model, instead of returning None we now
raise. Indeed return value was not consistent and 'None' is not something
people expect as tracking values. If the field does not exist tracking should
clearly say it, as it indicates a model issue somewhere.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
In old times, 'account' and 'project' supported 2many fields tracking. Then
it was moved directly into 'mail'. Thanks to precommit hooks and complete
record access for relational fields, it is now possible to track 2many
fields.
In this commit we cleanup odoo/odoo@167944cc93 that landed during work on this task and
add some tests to be sure it is effectively covered.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
SPEC 1: prepare all tracking values at same code place
Delegate all computation of tracking values into the 'create_tracking_values'
method. Curently part of it (currency field) is done in the caller. Better
split code per feature.
Method is also made private, as it is not required to expose it.
SPEC 2: cleanup tracking value formatting methods and calls
Code used to display tracking value can be simplified: remove unnecessary
wrappers, make code easier to read, avoid composition of field name but
use a mapping instead (easier to grep 'old_value_char' when it is effectively
used).
Ensure code always calls '_tracking_value_format' to ease future improvements
and have all formatting code being batch-enabled.
SPEC 3: simplify Chatter formatted value structure
'fieldType' is currently added in old and new values. As it is a field
property it can be moved higher in the formatting result to be included
only once. Also add 'fieldName', the column name, to the formatted results
as it will soon help various tool methods. Moreover it makes sense to have
the source of the tracking as the real column name, in addition to its
string and type.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
When possible, use '@users' decorator. Rename tests to better match their
main purpose, notably
* test_mail_track*: mail_track specific (specific fields, display)
* test_message_track*: overall behavior of 'message_track', notably subtypes,
template usage, ...
Add some additional tests and improve test coverage, as some field types
were not covered (date, datetime, text notably). Improve currency
check for monetary fields.
Move 'mail.tracking.duration.mixin' tests into the file testing mixins
linked to 'mail.thread', rename the Case class according to current test
guidelines.
Also starting from now, `MailCommon` flushes tracking automatically at
setup time, allowing to remove some custom flush done in tests. That way
tests are less prone to non deterministic errors. This implies some changes
in execution of tests, which means some updated query counters notably.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Ease unsubscribe page preview and edition. 'unsubscribe_from_list' generic
unsubscribe link now redirects to '/mailing/my' page, allowing to see what
an unsubscription page looks like. Empty sections are also added to ease
editor usage.
No real unsubscription preview can be done from 'unsubscribe_from_list' link
displayed in a mailing body as the mailing could not exist when clicking on it.
Moreover it would require custom code to redirect from this generic link to
the real unsubscription page, for few real added value.
Tweak access to allow mailing users to access a mailing given its non-protected
'mailing/<id>/unsubscribe' link. It is not linked to any backend document
(like specific document mailed, ...) but allows to display the page, edit
it, ...
Tweak 'mailing/<id>/view' to allow to generate the non-protected unsubscribe
link. It allows a mailing user to "view" a mailing, then click on "unsubscribe"
and land on the unsubscribe page, without having to deal with document_id
and tokens.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Add unsubscribe headers to email sent by mass mailings. As emails are already
parsed to change the generic 'unsubscribe_from_list' link to an email-specific
link we can add the List-Unsubscribe header at the same time. Add header for
post 'List-Unsubscribe=One-Click' to avoid one-click unsubscribe when readers
crawl email links.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Messages and notes are improved to have a better wording and links to contextual
records when possible (mailing, mailed records, contacts, ...).
Add opt out reasons when updating subscriptions or block list status. This
allows to better report on common causes.
For that purpose we introduce a new model allowing to store those reasons.
A boolean flag allow to trigger the usage of the feedback textarea in portal
page.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
In this commit we rename ``mailing.contact.subscription`` model into the
shorter ``mailing.subscription``. This is sufficient to explain the model
purpose. As we plan to add an opt-out model this also allows to have sub
models with suffixes without being too long.
We also rename ``subscription_list_ids`` field on contact model to
``subscription_ids`` as this is shorter and clearer.
Finally the ``mailing_contact_list_rel`` table name that comes from old
implementations (simple m2m table) is renamed to ``mailing_subscription``
to match the model name.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Currently mailing portal is usable only through dedicated links added in
mailings. Those use a hash token based on mailing, document_id (if mailing
ran on business documents) and email of the recipient. However this is not
convenient, especially for users that want to update their subscriptions
manually.
Purpose of this commit is to add a generic page in mass mailing allowing
to manage subscriptions to mailing lists as well as blocklist status directly
from portal. That way people don't need to come from a given email mailing
link.
A new page is added. It is located on ``mailing/my`` and has the same
capabilities as the unsubscribe pages, except it works outside of a given
mailing contact. Page (html, js) and behavior are shared among the various
use cases.
This page is available for logged user, both internal and share. Other people
should come through existing unsubscribe links using email, document id and
hash token.
Access control is updated so that it is now possible to use mailing routes
without requiring always email / document_id / hash_token. User can be used
instead.
A tour is added allowing to test this new feature.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Rename route parameters to be more clear about their usage. Notably res_id
is better labelled document_id, token is a hash_token, ...
Update legacy to still support old routes.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Globally improve usability and features given by mailing portal about exclusion
list and opt-out management.
SPECIFICATIONS
Purpose of this commit is to cleanup and improve the portal subscription page
that allows to manage subscription to mailing lists and blacklist status.
Main features updated or added
* allow to give a feedback when unsubscribing from mailing not related to
mailing lists. It was previously limited to mailings done on mailing lists.
Now the feedback is allowed in all cases and posts it on the related
document;
* clean display of opt-in and opt-out lists;
* display all public lists, even if not already join. This allows to opt-in
to new lists, which was not possible before;
* switch on a neutral name for non public lists (as they may contain
marketing hints);
* give UI feedback to customer when using buttons: add confirmation of
block list addition / removal, of updated subscriptions, ...
* globally improve wording;
Unsubscribe from a document now uses the same layout as unsubscribe from
mailing lists. Indeed the first one blacklists the email while the second
one opt-outs from mailing lists. But overall form is the same and options
are also the same. After all previous cleaning we can now keep a single
page for everything.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Purpose of this commit is to cleanup code that manages chosen lists from
portal and updates opt-in and opt-out accordingly.
Code is now located on mailing list model. When opting-it, new subscriptions
have to be created for mailing lists so that email is part of the list. When
opting-out we just have to toggle the opt_out flag on subscription model.
Logged messages are also improved. We log on contact model the updated
mailing lists for opt-in or opt-out.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Purpose of this commit is to get rid of old declarative javascript used in
mass mailing. It is still using old fashioned JS, not using widget or any
standard way of doing JS-based behavior in Odoo.
In this commit we introduce a main widget that manages the subscription page.
It has 3 sub widgets to manage parts of its features
* blocklist management: add or remove current email from exclusion list.
Adding an email in exclusion list is doable only if activated in settings;
* feedback: allow user to give their feedback. It currently logs on target
model, based on a hardcoded search on 'email_normalized' field. This is
strange as not all models have a normalized email field, but who am I
to judge anyway ?
* subscription management: allow to opt-in and opt-out from mailing lists;
This commit mainly keeps the current behavior, just rewrites the JS part.
Some further feature or UI update will move into sub-widgets in subsequent
commits.
Some Markup issues are also fixed in this commit, as code is already updated.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Main portal controller of mass mailing is currently the unsubscribe controller.
This controller has two main behavior:
* one is used when un-subscribing from a mailing based on mailing lists
(opt-out from lists);
* one is used when un-subscribing from a mailing based on documents (like
registrations or applicants). This one directly sets emails in exclusion
list;
Better split it into two sub methods so that it is easier to understand and
modify in future commits.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
Purpose of this commit is to better organize controllers about access control.
First do access control in a clean check method, then have business code. We
also use more frontend oriented errors like BadRequest or Unauthorized.
A main tool method now correctly raises depending on given input. Controllers
have the responsibility to let it raise, return a keyword of even skip error
if the flow allows it. If something is wrong, simply raise (http) or return
(json) generic errors in main cases to avoid leaking information.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
Use name instead of email, as contact is notably used in sms marketing
application with mainly phone numbers. Better use the name as primary
ordering field. Then use ID to avoid non deterministic behavior.
This requires to fix some tests in 'test_mass_mailing' so that they
use test models instead of existing models. That way they are not
dependent on existing data and existing models definition anymore. An
issue with ordering rose as we modified the ordering of contact model.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
Purpose of this test is to add tours and tests about the portal in mass mailing
that allows to unsubscribe from mailing list and to use the exclusion list.
This is done using small tours called from unit tests. Two type of tours are
added. The first one targets mailing done on mailing lists. As it targets
contact model unsubscription click opts-out the contact from the mailing
list. The second one targets mailing done on other documents. When clicking
on unsubscription link the document's primary email is directly added into
the exclusion list.
Some other additional tests are added to cover various use cases and features
of mailing controllers.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
There is a double list encoding, probably not required. Coming from mail
enterprise code move.
closesodoo/odoo#137451
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a computed m2m field giving allowed models for the action. It allows to
avoid choosing the wrong models when designing server actions.
Remove a test that has no use: it checks a model_id field is available on
server action view while we don't want to display it as it is imposed by
the rule itself.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
When creating new primary views you should always specify the priority to
avoid having the specific view used as default. This one is specific to
base automation usage of server actions.
Also move view in its own file to respect guideines. RIP JEM.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Effectively check that mail-specific server action types are triggered only
on mail-enabled models that are not transient.
Check that mail and sms templates models match their action model by adding
constraints.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Summary should be taken from activity types when possible.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Fix name compute method:
* correctly call super in batch;
* correctly filter records;
* remove dependency on context key (which was missing in triggers);
In this commit we also consider the name update should always be done even
outside of automated rules context. Having a whole compute method relying
on a context key does not makes sense. As server actions are technical
records, having the name always being correctly updated is better.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Following the recent server action refactoring, it seems translations have been
forgotten in the review process.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
New implementation of automated rules does not check if rule model matches
models of its children server actions. This can easily lead to updating
records of another model which have nothing in common with the automation
rule.
Also better write the reset when changing model.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Copy calls 'create' on 'self' which means self is not a void recordset. In
mail this causes issues as it may have an impact of values generated for
aliases, which depends on 'self' when calling '_alias_get_creation_values'.
Followup of odoo/odoo#130632
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#136968
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It was calling super of another method. But as the base code (located in
base/ir_mail_server) is the same, the result is actually the same.
Followup of odoo/odoo#130750
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#136968
RATIONALE
Merge two phone-related field on registration as they overlap. Having only
one is sufficient for contact-oriented model like registration.
SPECIFICATIONS
Registration model currently holds two phone field, phone and mobile. This
leads to having records with sometimes phone, sometimes mobile being filled.
This makes phone flows not easy: we have to define fallbacks (use phone or
mobile), data is not always synchronized, ... in the end what event users
need is one phone field to be able to communicate with attendees. Having
only one field is sufficient and simplifies the model.
Keep only one phone field, instead of two. Merge phone and mobile into a single
one, keeping phone as first value when having both available e.g. when
synchronizing with the partner.
Task-3366899
Part-of: odoo/odoo#128232
Co-authored-by: "Jeremy Hennecart" <jeh@odoo.com>
Some tests are updated to lessen diff in future tests, especially about
aliases. Some tests are fixed as they are somehow incorrect (notably
in gateway testing) but currently passing as mail gateway is quite
permissive.
Add some tests preparing MC / alias domains configuration notably about
company / alias synchronization, which is currently only based on config
parameters.
Also update some tests by using fstrings which are generally more readable.
Finally move some tests to their right file / main testing class to keep
them ordered by main topic.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#136318
X-original-commit: odoo/odoo@c18300e225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup some code bits in common classes, add some docstrings. Improve
notifications related helpers, notably to ease checking content of mail.mail
or outgoing emails when posting messages.
Update 'test_message_post' with those new helpers, to ease inclusion of
additional specific values test with alias domains in mind in next commits.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
X-original-commit: odoo/odoo@513fb74f5c
Part-of: odoo/odoo#136318
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make real subscription records for contact / list link, in order to have values
for inner model fields and ease their management / update / removal. It is
better than relying on m2m commands.
Also harmonize some xml ids names to ease future changes.
Task-2702607
Part-of: odoo/odoo#135299
Purpose is to ease tracking of data and demo through versions by avoiding
the usage of huge file. Instead split data and demo / main model.
Task-2702607
Part-of: odoo/odoo#135299
