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
The ETA displayed on a mailing should only switch from the scheduled
date to the next cron run when the cron run is after the scheduled date.
Previously it could jump in the past on the scheduled date, if the next
cron run was in the past (delayed or in progress).
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
The model MassMailing overrides read_group to handle the case when
it is grouped by field state, which is of type selection. However,
it sets as value for each group the array [key, name] of the
selection option, which is incorrect (it should set key as value,
like the default read_group does, and as the name is known client
side anyway).
This case was handled by the old views, but it isn't by the new
ones, which are less permissive. We choose to fix the read_group
override instead of allowing both cases in JS, as it is always
better to have a clear and single API.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
It is safer to avoid duplicates within a campaign,
so this should be turned on by default. Especially true
because campaign are often created without opening the
form view (quick create)
Also improved the description of the boolean option,
and made it editable in the form view, in case someone
wants ho really create a multi-step campaign.
Indeed due to onchange being trigerred at creation it breaks trying to
set default_mailing_domain when creating a new mailing through the web
client.
As setting domain and then changing model should not be the primary use
case of mass mailing, people will have to update their domain manually
instead of seeing it reset to a void domain.
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
Christophe Simonis