Composer in mass mailing mode currently keeps a copy of the emails in the
document communication history (chatter). It is done by keeping the
mail_message that is used to create the mail_mail record. It is now possible
to customize this behavior. Using auto_delete_message one can choose to not
keep a copy of the sent emails.
Note that the notification field on the mail_mail is used to know if the
associated mail_message has to be unlinked when unlinking the mail_mail.
Auto deletion of sent emails is based on the option on the template used
to generate the emails. It is now possible to bypass the template behavior
if requested, using the auto_delete field in the composer. If this field
is not set, the previous behavior applies.
It is now also possible to tune the message_type and subtype_id of the
posted message. Previously all messages posted through the composer
were comments with a computed subtype being either a comment or a note.
Those values are now default values but can be changed in the wizard
and correctly taken into account when posting the message.
Those modification do not change anything in the default behavior of the
composer and templates. They are mainly introduced for use in future
improvements in various addons, like sending reminder emails that are
not stored.
Correctly set the auto delete property coming from the template in the composer.
Set the mail_auto_delete context key for message_post, and directly set the
auto_delete field value in mass mailing mode.
When using a template adding the signature, do not re-add it when posting
the message on a document. For example the Sale Order - Send by Email
templates generated two signature in the email.
This issue has been introduced when migrating mail to the new API.
Use convert_to_cache and convert_to_read to format onchange values.
Fix: default value can be a command list, the onchange convert the comand list into a wrong comand list of command list.
Create `message_post_with_template` helper method to factorize the simulation of a mail.compose.message wizard.
Also, fix the generated attachments of mail.compose.message wizard by returning ORM command (6, 0, ids) instead of the list of attachments ids. In order to standardize the behavior of the wizard, and since the ORM support command assignation in onchange api.v8, all the x2many fields of the wizard return a command.
FYI, that was tde's idea !
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] bounce regex: too many emails were considered as bounce and therefore
not displayed in the chatter and lost for the communication history. The regex
was not correctly looking for the bounce alias in the email_to.
- [FIX] invite email: replying to the invitation email (invitation as new
follower) now replies to the user sending the invitation.
- [FIX] mass_mailing: added a column to store the id of the original email
in addition to the many2one column. The many2one is set to null when deleting
the original email. As the information is necessary, it is saved on another
field. The many2one is necessary for indexes purpose as the inverse of
a one2many.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
same_thread boolean field of mail.compose.message model define wether or not replies should be posted in the thread or not
On composer creation, this boolean should be passed according to the reply_to_mode of the mass_mailing
Otherwise, all replies would be posted in the thread, and the reply_to will be ignored (if same_thread id True, reply_to is poped from the mails values, mail/wizard/mail_compose_message.py:284)
- mail.compose.message: in render_message_batch, compute defaults recipients
for the composer (method called for mass mailing only). This way values are
available for inheriting models.
bzr revid: tde@openerp.com-20140325135347-9v7u4uokffy7ud43
cleaning in get_record_data + code cleaning in get_mail_values + management
of the previously introduced method get_default_recipients, to be sure that
in mass mailing an email is effectively sent to a customer / lead / applicant
/ ... because with an ill-configured template, you could have mass amiling
mailing nobody.
bzr revid: tde@openerp.com-20140321171723-7e3lk64knojf09at
to remove unnecessary code.
post and filter_id fields have been removed as they are not necessary.
Updated tests accordingly to new mass mailing tests: mass mailing create
emails, no message_post anymore using followers.
bzr revid: tde@openerp.com-20140317115315-ws8dvjbiv5rspk43
Local URLs are converted into absolute URLs, notably because when using the
email designer, images are added using local URLs. Previously to this fix
the template was analyzed to find local URLs and make them absolute.
However this causes 2 issues :
- mako-based URLs are broken because a scheme is added before the mako that
generated the image src
- when changing the base url, the templates are not updated
The URLs are now converted dynamically when generating the content of the
html. This is done by passing a new parameter that enable the post processing
of the generated content.
Also fixed double body generation when using templates; fields parameter
was not propagated correctly.
bzr revid: tde@openerp.com-20140304112957-l9b10gyjqphs5fgc
main differences :
- record_name is not a function field anymore, but a char field + a method in create
if not given (default-like, but dependent of other values). This allows the composer
to give a value for record_name (False for email mass mailing) to avoid browsing
records and having their access rights issues in the way
- author_id, email_from coming from composer instead of called in every mail.message
creation
- moved code dealing with attachments from send_mail to get_mail-values, to that at
the end of this method we know all values of the email
Some tests have been updated / temporarily disabled.
bzr revid: tde@openerp.com-20140224132038-txdi0g30a7fzbnxp
- now differentiates mass mailing and mass post.
- mass mailing is a true mass mailing
- using same_thread log a copy in the document, without using message_post
(using notification field, + model and res_id)
- improved form view of composer, adding a filed explaining a bit the various
recipients
- removed unnecessary fields coming from the template (partner_to, ...) because
they are confusing -> composer should be easier to understand and use
- removed some unnecessary code
- removed double body computation when using templates (one for tmeplate, then
the wizard -> not necessary)
This commit will be followed by other to try to improve the mass mailing
and mass post.
bzr revid: tde@openerp.com-20140220152945-ash0hfkzevzamihq
Otherwiwse if same thread is checked and post not, the reply_to is forced to the user email to avoid the email to be regarded as private without having a parent mail (has the parent is not posted in the thread), which is not what is expected
bzr revid: dle@openerp.com-20140210092301-1bdyvdwgekwgo9rh