Currently the rating value coming from the rating application is stored
on the message it belongs to. However storing it is not necessary as
there is no direct search using it. Having a computed field is sufficient
for all use cases we currently have in Odoo.
Removing the store allow to gain queries. Indeed the field is not
computed anymore after each message creation meaning we save queries
by not having to check existing ratings. It allows to gain a lot of
computation as mail.message is a critical model.
On the whole community runbot when installing all modules this leads to
a gain of more than 14K queries on 585K which means 2.4% of performances
increase. Considering the code size of this optimization this is quite an
interesting result.
Looking at test_mail performance tests we gain several queries (2/3) for
each new message which is coherent with the model change.
Finally it allows to lessen the performance difference between tests done
with test mail only and tests done with other modules already installed.
This is especially simple mail thread-enable records.
Related to task ID 51523. #Closes #23294. Done with blessing of @jem-odoo .
Send methods of mail.mail model are set private and simplified. Those
methods have been written when a lot of overrides were necessary to
generate notification emails. Since then the flow has changed but
methods have not been updated completely. This commit therefore simplified
a bit the call chain and parameters.
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.
Commit 0d3d0e9563 added a key in context when sending emails to know
the target model name. It was used at that time to forge for footer of
notification emails.
Since that time notification emails have evolved a lot. The code based on
that context key has been removed. Context key has been transformed into a
context switch. However it is not used anymore and can be removed. It allows
to clean a bit the code and save a context switch.
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.
This commit allows to gain some queries in mail sending process, meaning
removing context switch is interesting. One query is gained when using
the send process. Complex performance test involving several message post
gain 3 queries each.
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.
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.
Activity mixin adds an activity_date_deadline field that is a related on
activity_ids. This one is a o2m using a domain based on the current record
model. Indeed activities are cross-model, like mail.message.
However as it is stored it generates are a lot of unnecessary computation
when activities are updated. Indeed when activities change the related
computation is triggered for every model inheriting from the activity
mixin. It then applies the domain in order to find record to update. This
generates a lot of void queries because only one will match the activity
model.
This commit makes the field not stored anymore. Indeed it is used mainly
in filters. Same functional result can be achieved using a computed and
searchable field.
We gain a lot of queries when creating activities as indicated by the
counter update in this commit. Creating a record inheriting from activity
mixin is a bit improved since there is less computed field to compute.
Creating an activity costs a lot less queries and we gain about 40%
in term of query required to create an activity when a lot of models are
using the mixin.
On community runbot it makes a gain of 2% when installing all modules.
This commit allows to save 13K queries on 587K (current) which is quite
good.
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
This commits adds two tests in test_mail performance tests related to
the write operation. Indeed create a often tested but there are less
performance tests related to the write. Those two tests are
* first one is a simple write on a chatter-enabled model without any
tracking or specific feature; nothing should happen when performing
a write in that kind of model;
* second one is a write on a complex tracking-enabled model linked to
templates and auto subscription. It allows to have some figures for
real world use case.
Due to last commits that aim at improving Odoo performance all complex
tests of test_mail now take less queries to execute. Counters are
updated to match the current runbot behavior.
There is quite a big improvement when posting using a template compared
to other tests. As there are not enough tests to ensure all results
are correct let us stay careful by saying "it seems there are
improvements".
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
In order to really test a production environment we have to ensure
some mail related config parameters are set. This has an impact on
some tests.
Which is strange is that it lessens query number of a test that
already uses those parameters. Maybe XMas spirit.
As on enterprise module install order can be different from community
query count for some mail-related tests are different. This commit
updates some counters to avoid breaking enterprise runbot and give
time to find the source of added queries.
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that... for the employee login.
Thanks to the murphy's law, the test branch was green.
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that.
New tests are added in test_mail to have tests for message_post and
complex mail thread features. Purpose is to have performance counters
for more complex stuff in mail and begin to work on performances
and try to lessen those counters.
Add the context manager method `assertQueryCount` to count queries,
the decorator `@users(...)` to execute a test for several users, and
the decorator `@warmup` to execute a test twice (warm-up, then real).
Creating data directly in tests was done when tests were located in mail
module to avoid creating real data or demo. Now that mail tests have their
own module we can create demo data and use them in tests. It is simpler to
have demo data for things like subtype and email templates to ease
understanding and reuse.
Containing
* fix self._round not always existing;
* fix counter for activity creation;
* use self.str() in order to have some variation in test_mail;
* separate base performance to mail feature specific performance tests;
Test performance will now hold the base class for performance tests as
well as tests related to the ORM, depending only on base. A new module
test_mail is introduced at this commit that contains performance tests
related to mail module. This commit contains only code move and should
not impact anything.
Future commits will move mail tests into test_mail so that all mail
related tests are located in the same optional module. This allows
notably to avoid creating a lot of unnecessary tables when installing
mail module on production databases.
Thibault Delavallée