| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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 65ed4553a50fdbefc986b7d21f87a81c42b743c7
|
|
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
|
|
If the email is invalid (incorrect pattern),
the mailing status is set to canceled and will be flaged as ignored
in the mail.mail.statistics
|
|
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
|
|
|
|
|
|
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:
([^ ,;<@]+@[^> ,;]+)
|
|
NB: A controller in website_mass_mailing has been migrated too. It's not a real issue
as this module will also be migrated in the days to come
|
|
|
|
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
|
|
|
|
* [FIX] rename wrong mailing_type field and add missing fields when creating a mass mailing from the composer
* [FIX] coerce tooltip to an unicode string to avoid a json crash when locale produces a non unicode string for strftime(%B)
* [FIX] repair wrong sql statement computing statistics
|
|
- fixed keeping the original message for routing, only when choosing to reply in the
original thread (notification=True)
- auto delete sent emails explicitely
- mail_thread: routing: fixed replies always choosen even when replying to emails
with a specified reply_to (using ref_match in the algorithm)
- mail_thread: routing: instead of exclusive routing heuristics, use each case
as a fallback of the previous.
|
|
for mass mailing, composer and template. This allows to have one method computing recipints
and avoid repetiting myself.
bzr revid: tde@openerp.com-20140415154700-zu2izvxfjq1k4h4a
|
|
bzr revid: tde@openerp.com-20140414144011-awu4g35etq9s4gje
|
|
bzr revid: tde@openerp.com-20140414131109-7ijlz4gybjd2b2oj
|
|
- now body_html is a right field on mass_mailing, editable using the website
- email_designer controller / template now works on everything that has a body
receiving its model and res_id as post parameters; it does not work only on
email tempaltes anymore
- cleaning of the mass mailing form view: reply_to managment option (either
replied go into the document, either there is a specified reply_to; it is implemented
using boolean fields instead of a selection because all options are not available
for all models ... models like contact or partner do not have a chatter or
shoudl be be used for a chatter-like use)
- send to all now instantiates a mail.compose.message; the mass mailign processing
is delegated to the wizard itself.
bzr revid: tde@openerp.com-20140407170346-hpklabi513xskd07
|
|
bzr revid: tde@openerp.com-20140318132017-lx3c4yd9rbelc1an
|
|
- campaign appear only when having the group activated
- now choosing the mailing name, that create the mailing list + campaign
- currently limited to the valid models
bzr revid: tde@openerp.com-20140317165649-321f0wxatvj4pz5w
|
|
on the compose wizard
bzr revid: tde@openerp.com-20140109141856-xrublf8oi5mkutgu
|
|
- added fields on mail.mail.statistics form view to have all data;
- added comments;
- cleaned get_mail_values override now that statistics are created using o2m command
bzr revid: tde@openerp.com-20130917103555-jwhgl8y49g505ugz
|
|
mail_mail now have a statistics_ids field, allowing to create statistics when creating a mail.mail.
This is done in the mail composer, using classic o2m command. Mail_mail create is overrided to ipdate
the statistics value (message_id) that is computed directly in the create and not accessible
in the values dict.
Added model and res_id on stat model, to allow message_bounce update, without havign to rely
on the mail.mail existence.
bzr revid: tde@openerp.com-20130917094218-7jz5mnldogzhlioh
|
|
- fixed forgottent import of mail_thread in mass_mailing, to enable bounce and replied tracking
- fixed replied computation in message_route_process, adding the original email in parameters
- fixed form view of campaign, to add edit and dlete now that clicking on it redirects to the waves
- added track field on mail_mail, to avoid creating too mush entries in mail.mail.statistics
- fixed mass_mailign controller
bzr revid: tde@openerp.com-20130916114706-b9zyhp0ha6mr9fzg
|
|
Only remaining field is mass_mailing_campaign_id; if set, a new segment is automatically created
and its id is given to the created mail.mail.statistics using default value in context
bzr revid: tde@openerp.com-20130913132234-66vl19w54znky2rc
|
|
Mail statistics are now stored onto a separated object (mail.mail.statistics), allowing to
handle emails separately from statistics (among other removing mail.mail entries while keeping
statistics).
Everything linnked to opened/replied/bounce is not managed by mass_mailing, removed added code
in mail module.
bzr revid: tde@openerp.com-20130913115408-322cyjipdg680as6
|
|
It can be called directly from within the campaign form view, using a button.
It allows to easily create new segments and launch the composer.
bzr revid: tde@openerp.com-20130912100909-ofalececxn64a389
|
|
in mail.compose.message + form view cleanings + some fixes in mail_mail about set_opened/replied/bounced, now checking that ids effectively exist
bzr revid: tde@openerp.com-20130910151901-nhuwvtrkbwekyh7x
|
|
new module :
simple mass mailing campaign model, linked to emails, compute some statistics
mail.compose.message updated to the mass mailing campaigns in mass mail mode
bzr revid: tde@openerp.com-20130807130334-nwd34fgsz4lc6lt1
|
