render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
PURPOSE
Move links shortening tools on mail.render.mixin to have rendering and
post procesing tools available on that mixin.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
Steps to reproduce:
- install crm and mass_mailing
- go to crm > configuration > settings > activate leads
- go to crm > leads > select at least 2 leads > action > send mail
- set a subject > set a mass mailing name > send
Previous behavior:
you get a traceback
ValueError: Invalid field 'template_id' on model 'mailing.mailing'
Current behavior:
the mass mail is sent
opw-2212605
closesodoo/odoo#48088
X-original-commit: c87db90d5dbab4d02a9378a1fc905c9b2935cbe2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
When testing to send an email of a campaign from the automation
marketing app, a traceback is thrown.
This is due to a context error. We define a default value which isn't
possible to be assigned for the variable.
opw-2190077
closesodoo/odoo#47039
X-original-commit: ff1d42e26bca3ce60697f9d4ee28f6aae5b7046b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `unsubscribe` feature of mass mailings repose on having a link with
HREF attribute `/unsubscribe_from_list` inside the mail message.
When the mass mailing is sent:
- relative URL are replaced by absolute URL (`/unsubscribe_from_list` is
replaced by `{system parameter web.base.url}/unsubscribe_from_list`)
- `{system parameter web.base.url}/unsubscribe_from_list` is replaced by
the real mass mailing link containing info that will be used to
unsubscribe the user.
But there was an issue in the case of multiple domain, if this scenario
happened:
- system parameter web.base.url is http://domain1
- a user use "Test" button on a mass mailing
- system parameter web.base.url becomes http://domain2
- the mass mailing is sent
The unsubscribe link is broken, this is because the implementation of
"Test Mailing" feature would update the mass mailing with absolute
links, so if the domain change, we the `unsubscribe` link will no longer
be found and replaced into the source.
opw-2124890
closes#42373closesodoo/odoo#43308
X-original-commit: c5036bcb11fef8081f005fe4bd0025aea41401a8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
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 of this commit is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover it
is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed to
be accurate notably when involving super user.
Mail message creation could lead to desynchronized values between author
and email_from. This is improved with this commit by correctly inheriting
from default_get and computing both of them at the same time instead of having
two default values. Indeed they depend on each other.
Same thing is done for mail composer. Mail Thread offers a tool method to
find email_from / author_id based on having one of those values or current
user and it is called whenever necessary.
Some calls to mail template send_mail are also cleaned.
Task ID 1853147
PR #32243
In order to improve and clarify the mass-mailing (Email Marketing) module
several changes have been made
1 - Clarify the name of the application:
2 - Prevent the “Quick Add/Create” feature in the mailing kanban view
3 - Label and wording clarification in mailing_mailing form view :
4 - Clarify button names "Send now" ("put_in_queue")
5 - Mailing Form view layout
6 - Clarify the required field
7 - Clarify the readonly field
8 - Wording clarification if scheduling mail in the future
9 - Add a Placeholders tools page in the form view:
10 - Clarify the Campaigns view
11 - Clarify the Action Helpers
TASK-ID : 2046078
closesodoo/odoo#36124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Scheduling a mailing creates a wizard with a m2o linking the mailing. While
this wizard is still alive and not garbage collected it is impossible to
delete the mailing. This commit fixes that.
LINKS
Task 1997464
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
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.mail.statistics to mailing.trace and mail.statistics.report
to mail.trace.report. Rationale :
* mail.mail.statistics is linked to mail.mail model. Soon this model will
hold data related to SMS sending. It makes sense to be broader in the
naming;
* mailing.trace is more inlined with marketing.trace model that is the
marketing automation model using it in marketing automation (enterprise
application);
* mailing.trace is shorter to write;
* mail.statistics.report model should sense to be updated at the same
time;
MIGRATION
mail.mail.statistics model -> mailing.trace
mail_mail_statistics table -> mailing_trace
mail.statistics.report model -> mail.trace.report
fields updated (w column change)
* link.tracker.click: mail_stat_id -> mailing_trace_id
fields updated (no column change)
* mail.mail: statistics_ids -> mailing_trace_ids
* mail.mass_mailing: statistics_ids -> mailing_trace_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In mass mailing access to partners when performing a mass mailing has been
done in batch to speedup computation [1]. Emails are put into a dictionary
allowing to find back the email based on partner_id.
However the matching between the partner and its emails is done using a
shortcut using the current document ID as partner ID. It works when performing
a mass mailing on partners but fails when performing a mass mailing on models
having message_get_default_recipients not returning only emails. Currently
in saas-14 main models return only emails (crm, event, mailing contacts) but
other models may encounter issues (applicants, tickets).
This commit fixes it by correctly matching partner id and its found email.
Related to task ID 1924711
Linked to PR #32496
[1] See 65ed4553a5
To avoid sending mail to an opted-out mass_mailing_contact with email address
that is not strictly an email address (a <a@a.com> instead of a@a.com),
the the get_opt_out method must be adapted to use the email_normalized field,
as this method is only useful for that specific model.
Task ID : 1896677
Purpose : this commit improve various elements of the mass mailing interface :
- make recipients field in mass mailing form required and add "mass mailing contact" in selection
- new "Archive" button and color picker in dropdown menus of mailing lists and mailings
kanban views.
- various little improvements in labels
closesodoo/odoo#28497
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
In order to avoid sending mail indefinitely to a wrong email address,
Take the mail statistics for the recipient of the last 3 month :
if more than 5 mails bounced (with interval of more than 1 week)
the email is blacklisted.
Purpose
=======
- Apply the blacklist implementation to Improve mailing subscription to be more
compliant with the European GDPR law. Keep a list of people who does not want
to receive promotional emails (or mass mailing in general) anymore.
- Allows the recipient to update himself his mailing preferences
Specifications
===========
This commit is regrouping some main changes on mass mailing.
Apply Blacklist for following models through blacklist.mixin :
- crm.lead
- res.partner
- mail.mass_mailing.contact
- mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
as thoses pages should work without having the website module installed
Detailed implementation
===================
Mass-mailing :
- A blacklisted email is notified by the ban icon next to the email field.
(at the left of the email field for display purpose)
- Renaming the '_get_blacklist' method that was actually
searching opt_out list into 'get_opt_out_list'
- Opt out per mailing list : Add opt_out + related fields (for display and
ergonomy reasons) on the relational model
- Display relational model tree view instead of mass_mailing.contact tree
view when clicking on mass_mailing_list in kanban view
-> In order to be align between contact_nbr displayed in kanban tile and
the content of the tree view
-> mass_mailing contact is accesible via the user icon in this tree view
- Remove custom filters 'filter_contact_subscription' and
'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
model anymore
- Add 'is_public' to mailing list
The name of this mailing list can be seen (or not) by recipient in
the unsubscription page
If the mailing lists used in the mass mailing are not public,
the user in only informed that he has been unsubscribed.
If the mailing lists are public, the user is informed that he has been
unsubscribed from the mailing lists
and he has the choice to modify his subscription to all the public
mailing list he is or was subscribed to.
- Unsubscription Page :
- mass_mailing_contact :
Opt_out per mailing list, done by email and not by id, as multiple
contact can have the same email
The recipient can add/remove himself to/from the blacklist
The recipient can send a feedback about why he unsubscribed
- crm.lead + res.partner :
Once the recipient unsubscribe, he is automatically blacklisted
The recipient can 'Come back' and remove himself from the blacklist
if he changes his mind
- Show blacklist button parameter added in config :
The idea is to enable/disable the fact that the recipient can add
himself to the blacklist by showing or not the 'blacklist me' button
Only applies for mass_mailing.contact. The recipient, once
blacklisted, can always, no matter the value of this parameter,
'come back' and unblacklist himself
crm.lead + res.partner :
- Replace opt_out by blacklist in crm.lead + res.partner models.
As when a res.partner or crm.lead unsubcribe, we assume that the recipient
does not want to receive mass mailing anymore, at all, even if we adds him
to a mailing list afterwards. He is then blacklisted to avoid this.
With this behaviour, if a new lead is created with the same email address,
he won't be able to receive mail in mass_mode.
But he will still be able to receive '1 to 1' direct email.
Task ID 33224
Closes#25966
Purpose
=======
Improve mailing subscription to be more compliant with the European GDPR law.
Keep a list of people who does not want to receive promotional emails
(or mass mailing in general) anymore.
Specifications
===========
This commit is regrouping some main changes on mass mailing.
- Added blacklist : Avoid sending mass mailing to blacklisted recipient
(blacklisted = email address that doens't want to receive mass mailing anymore)
Detailed implementation
===================
Mail :
- Add Blacklist mechanism in mail module (NOT in mass-mailing) :
as we can send mass-mail without the mass-mailing module
- Unicity in email -> To avoid error in import, override the create and return
the existing record if any, else, create the record normally.
- Blacklisting is done by email address and is cross model.
Will apply to model that inherit the blacklist.mixin.
- field 'is_blacklisted' -> computed : check if email is in blacklist
+ search method to be able to filter on is_blacklisted
- When a email address is blacklisted, it will never get mass mailings anymore.
Even if the email address is added to another mailing lists
- Avoid sending notification to blacklisted recipients when sending email
in mass mail mode. If the recipient is blacklisted, we should not even send a
notification in the recipient's chatter for an email that he won't even
receive.
- When a email address is blacklisted, it can still get 'normal' mailings.
- The blacklist shoud be accessible in
Mass Mailing / Configuration / Blacklist
and Settings / Technical / Email / Blacklist
-> Renaming Settings / Technical / White / Black List config menu item
into Channel Moderation to avoid confusion with Mass Mail Blacklist
- Add indexes to the blacklist table (on email) to make it fast for access for
the different use cases
- _primary_email : attribute that must be overriden to specify which field must
be used as email in the blacklist mechanism.
- Filtering the blacklisted recipient in mail composer :
done in mail._get mail value()
In case of real mass mailing, we need the statistics to be computed in order
to know how many recipients were ignored in the mail.
So we cannot avoid sending mail but instead flag the mail as canceled.
Task ID 33224
- Email generated from mass mailing will have its own layout with internal css.
- strip_classes is removed from mail_message because mail client are now supporting
internal stylesheet. we need it for make mail responsive.
mail: manually removed classes from incoming mail body
Because we removed strip_classes from mail message body field because we want to
allow classes in outgoing mail to make it responsive but classes are not removed
from incoming mails so here we manually removed classes from incoming mail.
opw-1836556
Purpose of this commit is to re-arrange mass mailing buttons and to add
a button for scheduling mass mailing in future :
* add schedule date in debug mode;
* re-arrange all button;
* add schedule in future button and on click open wizard to schedule future
date;
* on 'send now' button remove the useless '|' in domain;
* add a small wizard to select the send date;
This commit is related to task ID 46932
When sending the test email of a mass mailing campaign, it might be
observed that the result is different from the final email sent to
customers.
This is because the `body` field of the final mail message is an `Html`
field with options `sanitize_style=True` and `strip_classes=True`. On
the other hand, the `body_html` field the test mail is a simple `Text`
field which is not sanitized.
We sanitize the `body_html` field with similar options.
opw-1820064
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
Purpose
=======
Mailing lists are not flexible. It should be possible to merge mailing lists and remove duplicates when doing it.
Specification
=============
- When selecting records, in the action menu, add "Merge selected mailing lists"
- A modal will open :
- There's the choice between merging the contacts into a new mailing list or an existing one
- There's the choice to archive the source mailing lists or not
- The duplicates are avoided in the destination mailing list
- Opt-out contacts are not copied in the destination list
This commit removes the strange selection box based on a magic flag and
some strange methods returning a string. Instead just allow to send mass
mailing on all models inheriting from mail.thread using the is mail
thread flag.
Various addons are updated to remove the _mail_mass_mailing class
attribute used to determine mass mailing capability.
We consider people could send a mass mailing on every model inheriting
from mail.thread. It makes no sense to limit it to a given set of addons.
When you send a mass mailing to muiltiple partner, if some of them have
no email adresse, it can lead to errors because of the variable 'recips'
is not set if the first occurence in the 'for loop' has no email.
To fix this, we always set the variable 'recips' by replacing the 'elif'
close by a 'else' one
introduced in rev: https://github.com/odoo/odoo/commit/65ed4553a50fdbefc986b7d21f87a81c42b743c7
Before this commit, the filtering brought by commit ca989b6 did not work when
no email_to was present. Which is the case for mass-mailings based on
res.partner records.
OPW 728321
Closes#16745
The mass-mailing App suffered from severe issues due to its inability
to detect and handle duplicates "at the email level", and the absence
of any global blacklist system, leading to lack of user trust.
Mailing-lists typically include multiple records with the same email,
and it is critical to avoid sending them the same email several times.
A related problem is the unsubscription of an email that is present
in other records (duplicates). Opting out the first email should
automatically blacklist it for other records as well.
Ideally we should have a global blacklist table in order to
share the unsubscription requests globally across models (Leads,
Partners, Mailing-list contacts). It would also allow importing
it from other blacklist systems. (TODO for master)
This commit introduces a partial solution, made of several
small changes:
- In mail.mail: double-check that an outgoing email has the
correct status (`outgoing`) before sending it. This allows
adding emails in the queue and cancelling them before they
actually get sent.
- In crm.lead: force predictable recipients for mass-mailing,
by always using the email of the lead rather than the email
of the linked partner when there is one. This simplifies the
computation of the blacklist and seen list. Other areas in
the codebase already assume as much.
- In mass.mailing:
+ Before sending out a mailing-list batch, compute the
blacklist (all opted-out emails) and the seen_list
(emails who previously received this mail) to make
sure we only ever target valid recipients.
+ While delivering the mass-mailing, any email targeting
an address that is in the blacklist or "seen list" is
canceled before being sent. The corresponding statistics
entry is considered "not delivered".
Also updates the "seen list" continuously.
+ When a mass-mail belongs to a campaign with the
"unique AB/B testing" flag, the "seen list" is
common to the whole campaign, as an extra safety.
+ Auto-delete mass-mailing test messages sent with the
test wizard, to avoid polluting the mail_mail table
Note: this fix uses a simple regex for efficiently extracting
the blacklist in pure SQL from different models, and doing so,
assumes that each record only holds a single email
(no comma-separated adresses). This should be sufficient for
most cases. The regex:
([^ ,;<@]+@[^> ,;]+)
The test wizard will be dropped eventually but it is not possible to delete
the mass-mailing before the transient is cleaned too due to the required field.
To make it faster, add a ondelete cascade on the field.
Closes#15217
When using the "Test Mailing" button, a sample mail was sent to a
particular mail address and a text-like unsubscribe link was added
below the mail body. This link was ugly, ununderstandable and useless
as it is test mailing anyway.
To add unsubscribe links to your mail body, use the footer blocks
which contain this kind of link (note: they are inserted by default
in all mail templates).
Martin Trigaux