This commit proposes to ease the use and specification of layout used to
encapsulate email body when sending notification emails. This is done
through two means
* message_post_with_template now supports the custom layout parameter
that allows to set the layout to use when sending notification emails
in the message_post process. We have to rely on the context as it is
the current way of using it in the composer. It is likely to change in
a near future;
* composer now supports through context (as we have no other choice)
specific notification values to give to the notification layout rendering;
This commit is related to task 51122 (and PR #24052).
When a mail is in failure state, a red envelope appears next to the message
in a thread but it was difficult to send the mail again.
This tasks will allow users to send mail again easily, or mark notification
as cancelled if the user want to ignore this failure.
A notification will appear in sender systray while mail are in failure.
Task: #46158
PR: #24628
Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes#21921.
Odoo puts in cache all stored fields of a recordset when you access the
first stored field not already in cache. In this particular case, Odoo
will put in cache all stored fields of 'mail.followers', which is
unnecessary and time consuming, especially on models where user follows
plenty of records.
With thousands of followed records, using a read() when searching on
followers is around 2.5 times faster than using mapped().
Record rules based on followers are speed up the same way.
Several contextual data is added in notification emails in their headers.
We consider as not necessary to put some of them, notably db uid. It should
not be used outside of Odoo and having Odoo-Objects should be sufficient
for people that want to categorize their emails.
In case an email received contains XHTML, `fromstring` fails because of
the following error:
> Unicode strings with encoding declaration are not supported. Please
> use bytes input or XML fragments without declaration.
opw-1832683
When parsing an email with some eml or dmg attachment, the parsing would
generate an attachment with empty content.
Since this content is later encoded in base64, it would crash trying to encode
None.
We simply do not process attachments without content.
We add a test to check that parsing mail with some empty attachment doesn't
crash, since the crash implies that the mail gets stuck on server
and is never fully processed by Odoo.
opw 1814014
message_post and various mail.thread related code still support a thread_model
context key allowing to redirect message post on another model. Purpose of
this commit is to get rid of that context key and support model / res_id
fields coming from either the record on which we run, either parameters of
message_post. Indeed those parameter match the one used as fields on mail
message. It makes sense to support them for customization if necessary
instead of using a context key.
This context key exists since a lot of time. It is difficult to find the
source as history is quite complex when the mail was refactored in 2012.
See notably 6aa4f80b2d and 2c4ed841b9 for example.
mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
In some cases when subscribing followers code may ask to force subtypes
of the subscription. It means existing followers should have only asked
subtypes independently from existing subtypes. Previously it was done
by unlinking and creating new followers for same partner or channel.
This commit proposes to instead update missing subtypes and remove extra
subtypes.
It has a small impact in real life as forcing subtype is not done often.
Some tests are improved thanks to this commit. This commit is linked to
task ID 1839043. Closes#24417.
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes. This
method should have the same behavior when author has no email. Currently
there is a crash when trying to encode its email. After this commit an
exceptions is raised like classic post.
This commit is related to task ID 1823990 .
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes and in saas
11.3 a message_notify has been added to notify peopel of a custom content.
Those methods should have the same behavior when author has no email.
Currently there is a crash when trying to encode its email. After this commit
an exceptions is raised like classic post.
This commit is a manual forward-port of 3a978cc64e6b1d8aca7cfd5d4e319bcb302dd262 as well as an improvement
to fix the newly-introduced message_notify method.
Cache invalidation when subscribing people has been added at e6f038a821.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.
However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.
Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.
Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c210923d.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.
This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.
A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.
This commit refactors mail.thread message_auto_subscribe method. Purpose
of this method is to automatically subscribe people to documents in several
scenarios
* followers from an umbrella record to sub-records, like followers of project
added to tasks;
* responsible of documents, in addition to sending notifications to newly
added responsibles;
* some specific use case depending on some applications like managers
for expense reports;
New auto subscription now uses the recently introduced method optimized to
compute new or to-update followers. It is also rewritten so that overriding
it is easier. Indeed simply overriding _message_auto_subscribe_followers is
now sufficient to add new followers to a record, depending on some updated
values. It is also now possible to specify a template to use for some
specific notification, if requested.
Fetching auto-subscription data in subtype is also optimized. It is now done
in a single SQL query. All data related to parent (like project) and child
(like task) as well as default and internal-only data is prepared in a single
query and given back to auto subscription process. This allows to gain
queries in auto subscription based on subtype like project / task use case.
This commit has a great impact on performance counters. Complex use cases
involving tracking and responsible notifications gain about 30 queries which
is about 15% of their total query count.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Override of create in mail.thread now uses the recently introduced
_add_default_followers to add the record's creator in the followers.
It allows to save one query when creating new records. It means for simple
models we approach the bottom limit in term of generated queries which is
quite a good news.
As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. We gain 1 query on most post due notably to
notify and logging is still improved. This leads to a gain of about 4K queries
on community runbot.
Use option recently introduced to use a minimal context when rendering
some mail templates such as
* notification template used to decorate messages sent to recipient
when using email-based notifications;
* user assignation template used when people are assigned on a record
and a notification is sent to inbox or email;
* message_post_with_template now uses minimal context meaning calls to
that method should be sure evaluation context is correctly set in
the given values;
This optimization allows to save some queries every time one of those
template is used, meaning all tests gain between 1 to 4 queries depending
on their complexity.
This commit is related to task ID 1817951. Closes#23291 .
Currently mail/view controller supports either a message_id, either a
model/res_id . Using a message_id is just a shortcut to find its model and
res_id before redirecting to the record view. If the message has been
removed the controller does not work anymore although with model and
res_id it still works while the record exists.
Same functional behavior can be achieved with only model and res_id. Let
us drop support of message_id to lessen code size.
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
1d57a09112 added a two-steps parent fetch when posting a message
on a discussion thread. At the time this commit was done responsible were
notified of the first thread message. It was helpful to notify them of the
original email that created the thread instead of the "document created"
generic message. Indeed for documents like leads or issues having the
original email containing the customer question is interesting when being
notified. This is why this commit was done.
However since quite a long time responsible notifications have changed.
They now receive an email notification telling they have been assigned on
a document. This commit is not necessary anymore and we therefore remove
it in order to clean a bit the message_post process.
This commit globally reverts 1d57a09112. Please note that @beledouxdenis
agreed after a long thinking.
This commit has a slight impact on mail performance tests, allowing to save
one query in some more complex test case.
Purpose of this commit is to simplify a bit message_post API. It has
a content_subtype parameter allowing to receive plaintext content.
It is then automatically converted into html.
This commit removes the parameter and consider the content is always
html. Code calling message_post should handle the conversion. In Odoo
the only use was in the chat_post controller that now perform the
plaintext to html conversion before calling message_post.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
Propagation was not correctly done at 8a026e26c6 . This commit
ensures all parameters are passed to sub-calls when redirection is done
in message_post.
* crm, hr_expense, mail
The nocontent helper can be generated either statically (in xml)
or dynamically (in python).
Before this commit, the result of some nocontent helpers was simply
the concatenation of the static and dynamic parts.
Due to recent changes (see https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417),
the nocontent helper has changed so that any of the nocontent helper
parts has to define its style for showing the face (e.g. smiling,
neutral, or folder face).
As a consequence of the changes above, the styles of some
nocontent helper screens were duplicated, e.g. two smiling faces
were shown instead of a single one.
With this commit, most dynamically generated nocontent helpers keep
only the dynamic part, so the static part is usually dropped in this
case.
Exception to above rule:
dyn_help = 'You could also add a new [document_name] by sending an email to [email_link]'
The dynamic part is appended right after the static help message, in its dedicated paragraph.
A new notif_layout parameter has been introduced at 304e6cf90b. However it is
not correctly propagated to sub-calls when redirecting message_post
using context and sub-model.
Current behavior when assigning someone as responsible of a document is
to send him an email if he works using emails. Technically it is done
when writing on user_id field and based on notification_type field value
of the user.
This commit changes that behavior to push a notification to the new
responsible. It uses the recently-introduced message_notify method
allowing to push notification to recipients without being linked to
a document. It means people working in Odoo receive a message in their
Inbox while people working by email receive an email.
Assignation message contains a link to the document meaning it is always
possible to go to the document. Notification email uses the new template
defined recently. It allow to have a notification email a bit classy.
This commit implies that more notifications are created. Indeed previously
to this commit no notification were created for partners without user
or for users working in Odoo. There is therefore a performance test whose
counter increases and a slight increase in query count when installing
all modules, about 1K queries on 581K.
Mail API contains a message_post method allowing to post a message on a
document. In some cases we would like to push notifications to recipients
that are not necessarily linked to a document. For that purpose we
introduce message_notify. It is a shortcut that prepares the message and
speeds up the computation by pre-computing message values. This method
calls message_post and therefore the whole notification process. It
means no custom code for pushing inbox or email notifications is necessary.
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 is to allow to add parameters to the view link. Currently it is
formatted like '/mail/view?model=model&res_id=res_id'. We would like to
be able to add parameters like access token for example. It will allow
to create view links specifically tailored for some people like customer
portal.
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
Tracking triggering subtypes are managed differently as they have a
business related meaning. It makes sense to notify them to followers.
This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
New record creation suck as new task or new ticket are linked to subtypes
people can follow and defined in their own module.
This commit introduces _message_log to use when logging notification-based
notes on a document. Its main purpose is to provide a shortcut to the
complex mechanism of message_post. As it is a lighter code and as it
performs less checks and value computation it allows to clearly gain
queries when logging notes.
It does
* skip the notification process completely. Side effect is that followers
following note subtype are not notified of document created and pure
note tracking. This is considered more as a fix than a feature change.
Indeed following notes means that followers want to receive notes
logged by other users. The fact that system notifications without a
specific subtypes are also notes is a side-effect of the current
implementation;
* support only notification-based notes and should not be used currently
when logging real notes as those could trigger the notification
process;
* skip access rights checks as it creates the message as superuser. It
is therefore defined as a private method and should be called within
a method where access rights are already granted;
On community runbot installing all 203 modules takes 580K queries instead
of 690 at the time of testing. It is a 15% performance increase based on
the 'all modules installation' metric.
In a distant future message_post and message_log could be merged after
some cleaning but it is easier currently to have this shortcut available.
Moreover as there are clouds on the mail module some developers prefer
to already have some optimization and code cleaning done to avoid
loosing all their hair.
This commit includes a small test. In a same distant future more tests
will probably be added depending on how mail API evolves.
Only messages as comments and email template should keep a white backround since they are not internal.
It is also enough to display fields that changed on subtypes (update message) since emails will be reworked soon and more information will be given there. The support of 'always' track can be removed. (is now considered as a simple tracked field)
The use of self.env.ref('mail.mt_comment').id add some query and the performance tests needs to be update since message_format is called by notify_by_chat. This code will be refactor later
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
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.
Notification emails contain a link allowing to follow or unfollow
documents directly from the notification email. However there are
several issues with this button
* it require people to login to follow or unfollow documents;
* it is not linked to the email;
* if the customer does not have a login it is not possible to perform
the action;
* there is no confirmation step;
This commit removes the follow / unfollow button in the notification
emails. Indeed as people have the "Access document" button there is
only one more click to perform in order to subscribe or unsubscribe.
Concerning customers adding a complete control of the follow mechanism
would be costly in term of code and access rights checks. We therefore
decided to remove this button.
It also allows to simplify a bit the notification process as there
are less parameters to take into account when grouping recipients. It
allows to lessen the number of required template rendering when sending
notification emails.
Pratima Gupta