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.
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
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 .
Purpose of this commit is to enhance quality of templates proposed by Odoo
and make them use notification layout when send by emails. Those emails
are cleaner and more up to date compared to other emails.
Including
* registration and reminder templates that are send directly by email
are improved to directly include the notification layout in the body
itself;
* improve layout of badge template;
* use notification layout when sending badge;
* improve layout of track confirmation template;
* use notification layout when sending templates based on stage change;
This commit is related to task ID 51122 (and PR #24052).
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
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
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
Yannick Tivisse