In case a default value is set for the field `mass_mailing_name` of the
mail composer, the automatic messages sent via message_post_with_* are
considered as a mass mailing. It may also create an AccessError if the
current user is not a mass mailing user.
In the case of the "assign user" email (for auto-subscribed users), the
url wasn't shorten, which resulted in invalid links (opw-752941) (fixed
by 3228694bdd)
A user without 'Administration/Settings' access rights cannot use the
'Retry' button on a mass-mailing.
This is because only this level of power is allowed to unlink
`mail.mail` records. However, this button is supposed to be used by
regular mass mailing users.
opw-744616
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
link_tracker use a regex to determine the content of
a 'href' tag, taking the 'mailto:xxxx@yyyy.zz' case
into account. mass_mailing use another regex that simply
don't.
So when sending a mass mailing containing email link,
the email will be appended by url path of tracking
url '/m/<stat_id>'.
This commit makes mass_mailing use the same regex as
link_tracker (which is in the dependencies of mass_mailing).
opw-727779
_rec_name in mass mailing is source_id which is an integer, it does not accept
a char value.
Instead specify the `name` value, which will create a utm.source.
Closes#13765
Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.
Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.
Previously Return-Path were composed using bounce_alias-<mail_id>-<model>-
<thread_id> . However this may lead to return adresses not supported by
the incoming mail server. We now form the bounce alias using bounce_alis+
<mail_id>-<model>-<thread_id>. Using a + indicates that the right part of
the address is for information and used to manage the bounce. Only the
left part is used for the email routing, allowing the return email to
effectively land in the alias mailbox.
mail.mail and mail.thread have methods to decode headers. This commit
move them in mail tools. It is indeed simplier to have all email tools
in the same file. Moreover they have been renamed to avoid confusion
with standard library methods: decode and decode_header already exist.
* decode in mail_message is now decode_smtp_header
* decode_header in mail_thread is now decode_message_header
A method to data from references is also moved into tools. A regex was
already defined in tools. Now the method using it is already put in tools.
Mailgateway will now simply call this method.
Now having
* sanitize: run the sanitizer to clean the html (removing javascripts,
unwanted tags, ...)
* sanitize_tags: only a subset of tags is allowed in html content.
Unwelcomed tags are remove dand their content stripped.
* sanitize_attributes: only a subset of attributes is allowed.
* sanitize_style: only a subset of style attributes is allowed. Style
attributes are parsed to keep only a white list.
* strip_style: all style is removed. It bypasses sanitize_style as there
is no need to sanitize something that is removed.
* strip_classes: remove class attributes
Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.
This group was defined in the mass_mailing module but is only working when
you install website_mass_mailing. What this group does is allowing to insert
a newsletter snippet in the page, thus it has nothing to do in the mass_mailing
module which doesn't depend on website. Also, the snippet itself was already
defined in website_mass_mailing.
Moved all the things to website_mass_mailing.
Since a324b22d, the mass mailing body editor would:
- save english body in language Y if user had language Y,
- not allow to edit translations in another language
This is due to how html_translate is set as translation function of html
only if the field is set as sanitize==True.
closes#13196
opw-685629
Rev. c9e38cae9f made the html sanitizer
stricter, and it will not badly break any attempt at composing
a good-looking mail template.
It will also strip all data-* attributes due to the default
`strict` mode, so any theme/snippets used in the template
will be dropped/crippled after saving.
mass-mailing templates are strictly meant for composing
outbound messages, and never displayed directly in users' Inbox
or published on the website. So there does not seem to be any
strict necessity to sanitize them.
When deleting the resource associated to a mail statistic,
e.g. deleting the lead associated to a statistic,
the statistic could not longer be opened.
opw-656738
_mail_mass_mailing attribute is evaluated at server launch (with no context) so
the attribute is never translated.
Create a new method in mail_thread to translate again the term at evaluation but
with a correct context.
Thanks to the _(...) in the attribute definition, the proper term is exported
and present in .pot file.
Christophe Simonis