As of rev. ca989b6548, the default
recipients of a model record are used to filter out blacklisted and
duplicate emails during a mass-mailing. This can match both either
partner_ids or emails, as returned by
`message_get_default_recipients()`.
The problem with even registration is that a single partner, sometime
anonymous (Public User) can be used to register several participants.
We therefore need to override `message_get_default_recipients()` to that
intent, similarly to what is done in crm.lead since
ca989b6548.
Without this, mass-mailings sent to free event attendees would never be
sent, as they would all appear to be duplicates of each other.
Fast-fwd port of 92a224ee3a
As of rev. ca989b6548, the default
recipients of a model record are used to filter out blacklisted and
duplicate emails during a mass-mailing. This can match both either
partner_ids or emails, as returned by
`message_get_default_recipients()`.
The problem with even registration is that a single partner, sometime
anonymous (Public User) can be used to register several participants.
We therefore need to override `message_get_default_recipients()` to that
intent, similarly to what is done in crm.lead since
ca989b6548.
Without this, mass-mailings sent to free event attendees would never be
sent, as they would all appear to be duplicates of each other.
Chatter suggests to include recipients on several objects, notably on
registrations. When a registration is done through a public interface
like website in website_event associated partner is the public user.
In that case proposing to mail the public user does not make sense.
It should propose the real email stored on the registration record.
To fix that we filter the partner if it is linked to the pubic groups.
The fix includes a sudo + context switch in a loop. As this method is
called only on a recordset of one element this has no impact on real use
case. Purpose is to keep the diff minimal.
Closes#23187 .
Before this commit, when a scheduler fail for one event (eg: error in send_mail),
the cron stop and don't continue to process all others event's scheduler.
Now we try to warn (~ randomly once by hour) the responsible/organizer/write_uid
that an error occurs with this scheduler, and we continue to process the others.
opw-1840497
closes#24741
If a country is specified, we show also all our online events to promote it since
they can be followed from anywhere. But we show in priority the physical event.
opw-1845012
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
Purpose
* move notify in message_post instead of always doing it at message
creation
Specifications
* message create should only create a message
* message post should be in charge of calling the notification process
- Steps to reproduce the bug:
Go to events ->Duplicate an existing published event
Try to publish that new event
- Bug:
You get redirected to the previous event webpage, which is already published.
Unable to publish the event from that page.
The url used to access the event is computed the function _compute_website_url which
a slugify of the display_name of the event.
opw:804118
Using `with_context({'use_babel': True})` overrides completely the
environment context. Therefore, the lang is lost and the date is
formatted in the default language.
opw-779753
This could be considered as a fix but was not able to be done in a
stable version as automatic mailing could be used to send non-reminders
emails. Or we could simply have users relying on the fact that
reminders could make cancelled attendees change their mind.
Method which return summary information about the registration,
which can be used by email or QWeb templates to fetch useful
information about the registration.
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.
Christophe Simonis