This module allows to define mass mailing campaigns and to have statistics about mass mailings. Each campaign holds several waves of mass mailing. Tracked statistics are the opening datetime, the reply datetime, the bounce datetime. The statistics are stored onto a mail.mail.statistics model. This allows to delete emails without loosing statistics.
Emails sent using mass mailing use a blank image linked to a controller that allows to track the opening of the email. When a reply goes through the mail gateway, the message_id in the email references is used to find its parent and, if found, update its replied date.
This module adds a new parameter, the bounce alias. If set, the Return-Path of sent emails is set to bounce_alias@alias_domain (i.e. bounce@mydomain.com). Any email coming through the mail gateway using this alias set its parent, if found, as bounced. If the related model has a message_bounce field, this field is incremented. This is for example the case for crm.lead model, allowing to filter and delete leads linked to a wrong address.
Misc :
- mail: test_mail_base is now called common; moved mail.group tests into their own file
- mail: fixed some issues in controllers (forgotten import, controllers not updated to new specifications of oe framework)
- mail, email_template, mail.compose.message: template rendering is now done in batch; now each template is rendered for all res_ids. Refactored email or mail_message value creation in mail.compose.message, to extract value creation from the process of sending emails. This allows to ease the inheritance.
- mail.compose.message: in mass_mailing, default value is to create a pure email mailing, not mass posting on document (aka, post is now False by default)
- mail.message, mail.followers: cleaned posting and notification email process, to lessen the number of queries to execute (read -> browse, refactored some methods)
- mail.message: cleaned form view, removing unnecessary group_by
- mail.message: reply_to and message_id computation in create now have their own methods located in mail_message.py (and not in mail_mail.py anymore for reply_to)
- mail.mail: slightly cleaned form view
- mail.thread: processing of routes in mail gateway is now done in message_route_process, extracted from message_route, to ease inheritance
- base_setup: added field in res_config to install mass_mailing
- crm: added message_bounce field
bzr revid: tde@openerp.com-20130917110214-z8494dfuok1g89lh
[IMP] read_group: added possibility to customize the group_by on datetime fields. A special context key can be used for datetime fields : datetime_format.
context[datetime_format] = {
'field_name': {
groupby_format: format for to_char (default: yyyy-mm)
display_format: format for displaying the value in the result (default: MMM yyyy)
interval: day, month or year; used for begin and end date of group_by
intervals computation (default: month)
}
}
bzr revid: tde@openerp.com-20130917110040-l3b5i0vk8qiwy0cm
- 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
- improved mass mailing wizard creation (everything is showed, better alignment, filter_id required, added default document on Partner)
- campaign: o2m is now readonly in form view, added an empty list help
bzr revid: tde@openerp.com-20130917085003-yof5gfy68y56ougf
- 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
The previous fix in revision 5072 only allowed user names
that contained the exact same emails, but users will do
the wildest things like having `someone@domain.com` as
name but setting their email to `someone@domain2.com`.
This was blocked by our sanity check looking for a single
email in the From header. As this check is only done
in order to provide a better error message, it should
not impact valid cases.
Modifying the check to pass when at least one email
was found should be enough to catch most invalid cases,
without requiring a more advanced analysis of the
header value (the RFCs allows very strange things!)
bzr revid: odo@openerp.com-20130918143807-wqqpqomyu1ppa2ih
The project_mrp process extends the sales process at
the procurement phase, however that part of the sales
process has now been moved to the `sale_stock` module,
which is not a dependency of `project_mrp` anymore.
There is however little reason to duplicate that
process node, so as a temporary hack, we can copy
its external ID, even though there is no direct
dependency between the two.
For next version we should fix this hack by moving
the node to a common dependency between sale_stock
and project_mrp, such as `sale`.
lp bug: https://launchpad.net/bugs/1223276 fixed
bzr revid: odo@openerp.com-20130918074002-wrhnq0w4t8xx3rgv
The project_mrp process extends the sales process at
the procurement phase, however that part of the sales
process has now been moved to the `sale_stock` module,
which is not a dependency of `project_mrp` anymore.
There is however little reason to duplicate that
process node, so as a temporary hack, we can copy
its external ID, even though there is no direct
dependency between the two.
For next version we should fix this hack by moving
the node to a common dependency between sale_stock
and project_mrp, such as `sale`.
lp bug: https://launchpad.net/bugs/1223276 fixed
bzr revid: odo@openerp.com-20130917160337-lih7bjqastozga8w
Darshan Kalola (OpenERP)
Thibault Delavallée
Launchpad Translations on behalf of openerp
niv-openerp
Denis Ledoux
Frédéric van der Essen
Olivier Dony
Martin Trigaux
Stefan Rijnhart