Right now, in our mass mailing, marketing users refine the audience they are
going to reach with our beautiful domain selector/editor. The problem here
is that the criteria that 'filters' audience can be very common and might be
used in many mailings.
Such filters have to be re-created manually each time they are needed unless
one duplicates a sent mailing. Another possible workaround is to access this
form view while in debug mode so that one can copy and paste those domain
expressions. Unfortunately, none of those solutions are either ideal or
convenient. Especially during the onboarding where new users are not very
familiar with those notions yet.
This commit allow users to save filters on the mass mailings. That way
favorite filters can be re-used on the next mailing. For that, we added
a new model 'mailing.filter'. We do not use existing 'ir.filter' model as
its usage is not completely the same and as we do not want to bloat view
filters with filters created on the fly in marketing application. This new
model contains the following fields:
- name (given by user while saving the filter)
- mailing_domain
- mailing_model_id (m2o for the recipient model)
- mailing_model_name (technical name of recipient model)
Users can create the filters by setting domain and then hitting hollow star
icon next to 'Filter' m2o and saving it with the name they want. Same way
to delete the saved filter, user simply have to click the filled star icon
when filter is already set. This is done through a new widget that adds its
own behavior on top of m2o widget.
The saved filters can be also managed with a new menu named 'Favorite Filters'
under 'Configuration' menu of Email marketing.
Task-2092853
closesodoo/odoo#70859
Related: odoo/enterprise#21049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This adds a series of CSS styles to the `<head>` of mailings in order to
ensure better mail client compatibility.
task-2554899
X-original-commit: ace475defca0c143d707f7b53d9f19a9db6cfe3e
Part-of: odoo/odoo#77724
This brings a series of improvements to the mechanism in place to
convert the output html of mass mailing into html that is more compliant
with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into
table structures. Currently all templates in `mass_mailing` are designed
with tables so they work in mailings as is. That has limitations though
as it makes it less easy to edit with snippets such as those used in the
website builder. This new automatic conversion from Bootstrap grid will
allow us to adapt the mailing and snippet templates and be more free
within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this
doesn't support the mixing and matching of column options
(e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
task-2554899
X-original-commit: e2e00939e09220051f6f4ecfb7bb3276105387bf
Part-of: odoo/odoo#77724
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Since the introduction of Odoo Editor, `field_html`'s `_getValue` uses
`wysiwyg.getValue`. This conflicts with the mechanism of `mass_mailing`
which modifies the html of the editable area in place to save an
"e-mailable" version on the `body_html` field, then relies on
`_getValue` to reset the original html (`body_arch`).
This ensures the field has a value before modifying the html in place,
so we can manually restore it instead of relying on a side effect of the
old behavior of `_getValue`.
Part-of: odoo/odoo#75901
Manage correctly a/b testing in mass_mailing.
We can now organize a mass_mailing campaign by testing
multiple mailings for the recipients targeted (subject,
templates, design, ...)
For this a new tab on the mailing record is added to better
promote the existence of the feature.
When an user has the group to manage mailing campaign, he can
access the tab A/B Test. This tab allows to enable A/B testing
for the mailing. If there is no campaign set for the mailing,
one is automatically created allowing the user to continue
smoothly.
Once A/B testing enable, the percentage of recipients use can be
set for each mailings. Also, the user can choose the deciding factor
that will set the final mailing as winner.
In a case, the user is not in manual mode, he can set the schedule datetime
for sending the final mailing.
task-2123242
COM PR: odoo/odoo#75622
ENT PR: odoo/enterprise#20454
UPG PR: odoo/upgrade#2781
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Improve modeling and performances of mass mailing by manually updating trace
status instead of using complex computed fields and lessening fields usage.
Remove some fields and keep only relevant metrics to simplify and clean trace
model.
SPECIFICATIONS
In this commit we clean the way trace state is managed. Currently it is a
computed field based on several datetime fields. However this generates a
lot of noise in the table as well as unnecessary computation
* there are several columns (one for each state) storing datetime at
which status was reached. Generally only 2 or 3 contain relevant
information;
* state could be set in code directly to avoid a computed field based on
many triggers;
* recomputing it each time a date changes is not necessarily necessary;
* state value can always be updated manually as this is main done through
some automated server update (mailgateway, link clicks, ...);
As trace states and its triggers should not be updated manually it is better
to synchronize it in code flow. When there is an exception or update done
through sending or gateway status is updated as well accordingly. Various
datetime fields are also updated at the same time. In order to align with
notification model mail and sms trace status are updated to a classic field.
Only last status update is now kept as there is no need to store the entire
history of status change.
We keep only a datetime for relevant metrics: open, reply and click. Other
datetime bring no real value. Knowing when a trace was in error or bounced
is not necessary. Indeed exception generally indicates a server issue (at
sending), cancel indicates a data issue (at sending) and bounce depends on
customer email server.
Status update is removed as using write_date is sufficient. Once created
traces are updated only when an external event occurs (opened, replied, ...).
It allows to simplify trace model.
We also rename ignored field into canceled to match naming use through mail
and sms.
QUERY COUNTERS
This change has some positive update on query counters when sending mailings
as traces have less unnecessary status update compared to priori this change.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
SPECIFICATIONS
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
SPECIFIC USE CASES
* recipient without email / number: mail / sms is set as canceled, trace is
ignored;
* recipient with invalid email (no @) / number (formatting impossible):
mail / sms is set as canceled, trace is ignored;
-> we now distinguish when possible a void email from a wrong email using
a newly-added selection key (mail_email_missing);
* recipient with email / number blacklisted: mail / sms is canceled, trace
is ignored;
* recipient with email / number that optouted from mailing: mail / sms is
canceled, trace is ignored;
* recipient with email that bounces: mail is sent and will be set as bounce
when receiving bounce in gateway; trace follow same path;
* recipient with number that bounces: not supported as currently no support
of bounce through IAP;
* mail server error, IAP error: mail / sms is set as exception / error,
trace is set in exception;
This means we introduce new failure types on mailing.trace model to reflect
those failure types
* ``mail_missing``: missing email (different from wrong value);
* ``mail_bl``: blacklisted;
* ``mail_optout``: optouted;
* ``mail_dup``: duplicated email skipped during mass email send;
We introduce ``sms_optout`` on SMS and trace models as it was merged with
blacklist previously. Now both errors are distinguished.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
PURPOSE
Remove hardcoded list of models on which mailing is possible. Indeed it is
not modular and not really smart with enterprise code not being reachable
in community.
SPECIFICATIONS
Replace hardcoded list of models on which mailing (both mail or sms) is
possible by a computed searchable field on ``ir.model`` based on a class
attribute.
It allows to cleanly define models having mass mailing capabilities and add
this attribute in bridge modules (when existing) or directly on base model
definition to avoid bridge modules.
In this commit we introduce a basic ``_mailing_enabled`` class attribute
activating mailing on model.
Mailing models may also have a ``_mailing_get_default_domain`` method allowing
to define a custom default domain when sending a marketing mailing on records
on this class.
Mailing models can now define a ``_mailing_get_opt_out_list(_sms)`` method
allowing to define custom behavior to fetch opt-outed records. Instead of
defining a model-based behavior on Mailing itself, it now calls the model
defined one. We still have two methods, one for mailing and one for SMS
opt out computation as it relies on different underlying models and fields.
LINKS
Task ID-2431217
COM PR odoo/odoo#67322
ENT PR odoo/enterprise#16876
UPG PR odoo/upgrade#2236
Make the email body take the entire space to avoid having some wasted space,
this will also make the user have more focus when designing an email.
Revamp the settings notebook page in order to give more clarity to the user,
and move some fields from the main form have been moved to this section to
have more space in the bottom for the email body.
In the mailing form, when the mailing is sent or is being sent, set fields
which are no longer useful for the user to change to readonly mode.
Add a wizard that enables the user to schedule a mailing, the schedule field is
still kept in the form for the user to be able to change the date when the
mailing is in the queue (if they want to send it sooner).
Display an action helper-style content when the email is empty, because,
currently, the user is left with a big white screen when the email has no
content which is not desirable.
Update the html_empty function to take into account style attributes to better
match the editor's void content.
Hide A/B testing fields from SMS mailing form view as these are not supported
for SMS marketing.
Task-2469409
closesodoo/odoo#68882
Ent-pr: https://github.com/odoo/odoo/pull/68882
Related: odoo/enterprise#18391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
qweb returns bytes, which would be stored in a dict's `body_html`,
which would then be stringified *but not decoded*.
Running with `-b` this gets flagged, it's probably better to fill the
dict with what's actually expected (text).
Propagate reply_to radio keys (update and new) to mass mailing in order to have
a coherent naming (was thread and email). This naming is also coherent with
gateway naming (message_update and message_new).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Purpose of this commit is to add tests for current behavior of ``keep archives``
field on mailing, used in combination of ``reply-to`` target (either new thread
or update existing threads).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
Since PR #55995 is merged, we get traceback while trying to merge the
mailing lists. This has recently been fixed in odoo/odoo@fc1005aa1e .
However code can still be improved to correctly take default values from
context instead of always relying on active_ids, as well as ensuring we
are effectively working on mailing lists.
Apart from that, this commit also shortens the action name to 'Merge'
from 'Merge Selected Mailing Lists'.
Task ID-2471692
COM PR odoo/odoo#67213
X-original-commit: 58722d7e855aac75f76e48c24265130c7f03cec9
What are the steps to reproduce your issue ?
Try to merge two mailing lists
What is currently happening ?
Traceback
opw-2504230
closesodoo/odoo#69601
X-original-commit: 66af485530cfc2f5e224b70850b011f0c05743d0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Purpose is to have more tests when sending mail mailings, notably about
canceled or failed mails or sms as well as jinja and links rendering.
SPECIFICATIONS
In this commit we improve Email Marketing mailing tests. We notably
* add tests for void and invalid email and numbers. It allows to check they
correctly update their trace status;
* add tests for unsubscribe and view links embedded in mass mailing emails;
* add tests to simulate a click on links sent through mass mailing and
ensure click statistics are effectively updated;
* add tests to simulate bounce emails coming back to the mail gateway;
Default content of mailings used in test is updated to ensure jinja is
correctly rendered, including links and some corner cases. This will also
helps ensuring behavior is kept when converting to QWeb.
Various docstrings are added to helpers and custom asserts.
LINKS
Task ID-2508643
Followup of odoo/odoo#68874 (improve mail tests)
Prepares Task ID-27033 (support QWeb in templates)
Prepares Task ID-2377974 (clean trace and status management in mass mailing)
COM PR odoo/odoo#69461
ENT PR odoo/enterprise#17780
X-original-commit: 7b940ad46bde30f9bf16837f7bff5a70cd88c640
When using assertMailMailWEmails custom assert we now check that a sent
mail.mail matches a sent email. It allows to have a complete check from
mailing traces to sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
ENT PR odoo/enterprise#17558
X-original-commit: 59da8627e0d732b12fb98faa6e66e43b8c75dc9c
In this commit we backport some of 14.1+ improvements done in mail tools
in order to keep a coherent definition through sub versions. We also
improve docstring and add some explanations on available toold and asserts.
Task ID-2500615
COM PR odoo/odoo#68874
X-original-commit: d44c47697389866603f28ff2d5da60a97574ec5f
This commit handles 2 things:
- Clarifies why some inline style has to remain inline instead of being moved
to a separate file.
- Moves an inline modification to field_html for testing purpose to
a dedicated file.
This has been done to improve consistency in asset bundles declarations
by reducing them to the simplest possible templates.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
When testing cron triggers, it is common to get the newly created
triggers in order to validate they exist and are scheduled are the right
moment.
This new helper is a context manager that capture all triggers or
triggers created for a specific cron. The created triggers are
accessible via the context's object `records` attribute.
The various tests have been updated so they use that new helper.
closesodoo/odoo#68163
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
This commit introduces a new wizard that allows adding existing contacts of a
specific mailing list to another mailing.list.
It's typically used on the list view of a mailing.list where you tick a bunch
of contacts and add them all at once to another mailing.list (existing OR new
one that you create on the fly).
That tool will help users manage their mailing.list a bit easier and avoid some
tedious copy/pasting if mailing.lists need to share common contacts.
Wizard has two options: either simply create a new mailing list, either create
it and use it directly in a new mailing. It allows to cover the following
user flow
* select contacts;
* add them in a new list created on-the-fly;
* jump on a new mailing targeting this mailing-list;
* fill body, launch, enjoy !
Task-2453990
closesodoo/odoo#65965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Noureddine Bensebia <neb@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Purpose of this commit is to better differentiate channel members technical
model from partner members in code :
* ``channel_partner_ids``: contacts member of a channel, filtering notably
on active and checking ACLs on res.partner business model. This one
should be used whenever we deal with members of a channel at business
level;
* ``channel_last_seen_partner_ids``: memberships of a channel and technical
model. This one should be used for internal processes and members
management;
Also containing
* clean naming or API of methods managing channel members. This should
not change anything functionally as only code renaming / cleaning is
performed;
* improve performances of channel member auto subscription by aggregating
all members to add and creating them at once;
* check the use of ``mail.channel.partner`` and ``res.partner`` records
through ``channel_last_seen_partner_ids`` and ``channel_partner_ids``
Channel fields;
Functionally nothing should change with this commit. It only cleans code
in order to prepare future modifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
The "launch" button of an email campaign mark the current campaign ready
to be processed. As sending all the mails is a pretty heavy operation,
it is done asynchronously in a cron. The cron was running every hour, it
means the cron was running even if there was no active campaign and it
has a best precision of 1 hour.
We now use the new mechanism of cron triggers (4b28f11) to schedule the
con execution at the time the campaign is configured to be sent. It
achieves a better precision and ensures the cron only runs when there are
stuff to process.
We still let the cron run once a day as a security until the cron
mechanisme proves reliable.
closesodoo/odoo#65124
Task: 2416741
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before this commit:
While trying to duplicate a mailing contact within particular
mailing list, it throws an user error saysing that 'A mailing
contact cannot subscribe to the same mailing list multiple times.'
After this commit:
User can duplicate a mailing contact from a mailing list without
the user error. In this case, we simply remove the default_list_ids
from the context, because all the mailing lists will be simply be
copied over from the existing contact and so we don't have to
re-add the default ones.
closesodoo/odoo#67094
Task-id: 2431344
X-original-commit: b92ebf3a47b7b1263669ac020ac8c213027400ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This partially reverts commit 1ec887b773,
which was a hack to deal with the issue. From now on, the first call to
onchange() no longer computes editable fields when they are given a
default value.
X-original-commit: c01657d345f59e3ccea70a5004732050fae99320
When creating new contact coming from a mailing list a default_list_ids
context key is set. It is used to give a default value to list belonging
and also to compute opt_out.
However subscription_ids field is displayed on contact form view, allowing
to add the contact to mailing lists. We may end up in situation where a list
is given twice to a contact: once through default_list_ids and once through
subscription_ids field manually completed by users.
In this commit we therefore merge those two values when creating contacts.
Also improve some wording while we are at it.
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031
X-original-commit: 30bab79183b4b9f1a571d6ebd9bbc1f3c0692457
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
Purpose of this commit is to improve tracking of opened traces. Notably
a token is added to ensure we do not mess with traces and have unique
tracking URLs.
MIGRATION REMARK
Emails sent before the migration will not be marked as opened anymore after
migration. We recommend to avoid sending statistically important mass mailings
about one week before migrating database. Indeed statistics show that most of
open emails happen within the first week after being sent.
Task 2223146
closesodoo/odoo#49139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
URPOSE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Add tool methods and asserts for link tracker tests.
Add tool methods and assets for mass mailing tests, notably about mailing
traces and their link with emails.
Merge existing and duplicated tests and rewrite them a bit.
Rename and improve test_mass_mailing models.
LINKS
Prepares task ID 2238597 (notification and trace models cleaning)
Task ID 1906925 (mass mailing tests cleaning)
PR #50169
Related: odoo/enterprise#10180
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently mailing_domain is a computed editable stored field. Its mailing
domain is either computed based on current model (taking into account
blacklist, opt-out, ...), either manually crafted.
However current implementation does not support default values coming from
context as they are reset by the triggers of the computed field. This
commit fixes that behavior.
Tests are added because somehow we should find a way to stabilize mailing
domain computation.
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Task ID 2119333
PR #40949
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update this module to new tools / asserts / helpers / classes defined in mail
and test_mail.
In this commit we remove the ``MassMailingCase`` and replace it by a fresh
``TestMailCommon`` that is simply updated to hold a marketing user by default.
That way all mocks and asserts are available in all sub test classes.
Coming from common update, we have notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
LINKS
Task ID 2068986
PR #38070
The link tracker model (link.tracker) contained favicon (store)
and icon_src computed fields. Computing favicon took
{3-6.5%} of installing odoo (with demo data) due to syncronous http
call to a external link (google).
Moreover, these fields had no sense to be store in odoo
and only used in one template. This template was modified to
display the same information (icon) as before but without storing fields
and with a lazy loading of icons.
TASK_ID: 2083715
closesodoo/odoo#38405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Prepare mass mailing module to addition of mass_mailing_sms.
Mailing model: mailing type
* add a mailing_type selection field;
* mass mailing contains only 'mail';
* synchronize medium accordingly;
* update actions of mass mailing application to add a domain on mailing
type being 'mail';
Mailing contact
* remove is_email_valid field as its purpose is achieved by email_normalized
field coming from address mixin (added by blacklist management);
Mailing contact subscription
* clean a bit fields and views as this should stay a technical model;
Trace model and report: trace type
* add a trace_type selection field;
* mass mailing contains only 'mail';
Various
* clean some bits of code in views, remove old code bits;
* add anchors to ease view inheritance to be able to customize views for
SMS mailings;
* ensure all views in mass mailing filter content on mail type (mailing
and traces being type mail only);
* rename some methods to be more updated with current guidelines, notably
main action methods;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
PURPOSE
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. We will also add relevant
statistics on utm campaign model in order to use it in various applications.
SPECIFICATIONS
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. This change implies that
mass_mailing.tag and mass_mailing.stage have to move to the utm model along
their associated views/data.
These changes were made so that campaigns could be used in the future
by social, mass_mailing and mass_sms and available in the same view
This commit also removes the source_id and the medium_id
fields on the campaign.
This commit also moves the unique_ab_testing field from the mass_mailing_campaign
to the mass_mailing model
Task ID: 2002029
PR: #34015
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing model to mailing.mailing. Rationale :
* mailing is now a prefix for mass mailing models;
* mailing.mailing is easier to read / find / understand;
Note that mail.mass_mailing.campaign is not updated as it is likely to be
removed soon and replaced by simple utm.campaign model.
MIGRATION
mail.mass_mailing model -> mailing.mailing
mail_mass_mailing table -> mailing_mailing
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :
* those new names are easier to understand: mailing.list and mailing.contact
are less mail-related, especially taking into account that SMS will allow
to be less mail-oriented;
* those names are easier to read / find / understand;
* align wizard and sub-models naming with the main naming;
* have a mailing as first part of namespacing;
MIGRATION
mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)
fields updated (no column change)
* mailing.list: subscription_contact_ids -> subscription_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
Munaf Khan