Purpose of this commit is to improve performance of post and notify through
various code improvements.
Containing
* making of _notify_customize_recipients a mail.thread method;
* _message_auto_subscribe_followers optimized;
* renaming and optimisation of _notify_partners;
* message_post_attachements optization;
* remove unused mail_post_autofollow_partner_ids context key;
* minimize message create queries;
* only check record related access right for thread messages not in pending
moderation;
* get attachements from values instead of db;
* storing lang in ctx from the beginning;
* don't track on write on attachments;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
It includes notification on inbox / email as well as attachments management.
This latter one adds quite a lot of queries and is not currently tested
for performances. Future commits will improve those counters.
Related to task 1943901
Linked to PR #32404
Currently if a message has a res_id and a res_model it appears in the
matching record's chatter. Its access rights are computed based on this
record. This is the standard behavior of mail.message model.
User notifications are currently built on messages not having model and
res_id in order to avoid appearing on chatter. This has several drawbacks
notably access rights, redirection to the record, systray, finding back
records, ...
This commit solves those issues by adding new message_type 'user_notification'
that should be as a classic mail.message with model and res_id but without
the whole notification mechanism and without being displayed in the chatter.
An user notification is now a classic message pushed to a given partner only
and not displayed in the chatter.
Related to task 1943901
Linked to PR #32404
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Base issue: unnecessary inherit of composer on mail.message. Indeed there are
a lot of unused fields coming from mail.message as well as message specific
behavior (notify, check access, various business methods) not relevant for
composer.
Specifications
* remove inherit from mail.message;
* re-define used fields;
* ensure everything still works;
Commit linked to task ID 1907153 and PR #28464
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Some counters are not up to date notably taking in to account community-only
and test-mail with enterprise only counters. Those are used notably when
developing to ease quick check of counters.
closesodoo/odoo#32370
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Currently fields with a `groups` attribute can't be tracked.
Otherwise changes would be visible by all in the chatter, including
users which normally don't have the access rights because they are
not members of `groups`.
Specification
=============
Filter tracking field values according to the `groups` attributes.
Users without the access rights should not see them.
If a message is only composed of tracking values and the user doesn't
have the rights to see them, an empty message should not be displayed.
This commit changes some methods so they can be used in the account_documents enterprise bridge
and adapts activity tests for the new request on upload_file feature.
task: #1928404
related to: odoo/enterprise#3607closesodoo/odoo#30950
1) Configure both an incoming mail server and an outgoing one.
2) Install CRM.
3) Create a sale team, use the incoming mail address as mail alias.
4) Add a user with a valid email as follower of that team in the
chatter.
5) Enable developer mode, become super user via the developer tools.
6) Change the language of the super user to french.
7) You may want to modify the default gather/post time interval.
to receive/post email more regulary in the scheduled action.
8) Using an external mail client, send a mail to the incoming mail
address.
9) Let the two scheduled actions run by themselves.
10) The mail sent to the user has the "Lead/Opportunity" in english
wheras the rest of the email is in french.
opw-1917993
closesodoo/odoo#31034
Do not use the model `_description` field which cannot be translated. Use
the `display_name` of the corresponding model instead.
Moreover, `<t t-esc="'%s' % model_description or 'document'"/>` gives
`'None'`, while `'document'` is expected.
This adds a query to some tests, which is expected since `display_name`
requires information stored in the DB, while `_description` is defined
at the Python level.
opw-1908420
When a letter is sent through snailmail and encounter an error, it used
to create an activity to the user to notify him that there was an error
with its letter.
When a user had this activity, he didn't have any clues of what was the
error and how to manage it. So we decided to better handle snailmail
errors and give the possibility to the user to easily fix the source of
the snailmail errors.
First to give a better feedback on the letters in errors, we've made
features similar to ones existing for emails:
- We add a mail message on the document that sent the letter, and put a
small paper plane icon, which is red when an error occurs (like the
envelope for email)
- As letters can be sent in batch, we've also added an entry in the
systray to easily manage the different documents having snailmail
errors like for emails.
Then we identified, the most common errors encountered with the
snailmail letters and give proper way to let the user fix them:
- Missing Required Field:
- The address is not complete, some of the fields are empty.
- We open a wizard allowing the user to modify the partner address
and we try to resend all letters having this error on the modified
partner.
- We also try to avoid this error, by opening the wizard before
sending the letter, but it only works for single documents, not
for batch.
- Trial/Credit Error:
- The user has not enough credits to send letters anymore.
- We open a wizard that give a redirection lnk to add credits on its
iap account.
- No Price Available:
- The destination country is not supported by any of our providers,
and we cannot do anything to send this letter.
- Format Error:
- The format of the pdf report send by the user is refused by our
providers, because some visual stuffs are not respected, for
example blank zone to print barcode or margins.
- We show a wizard to the user letting him check a setting option
that add a cover page in the envelope and the documents will be
send with this extra page containing the address.
- Unknown Error:
- This is not one of the listed error above.
- A wizard suggesting the user to contact support is displayed.
The cron that try to resend letters on error, has been addapted to only
try to send the error of type Trial/No Credit, because the account might
have been reloaded, and other errors, won't change if they have not been
fixed locally.
closesodoo/odoo#29685
This commit introduces the "upload file" activity type
category. For an activity of that time, uploading a file
will mark the activity as done (and maybe create the forced
next activities).
This activity type is seen as a shortcut to upload a file
with a reminder.
Task-1915004
closesodoo/odoo#29861
This commit improves code of access rights checks when creating or updating
activities. Several points triggers this commit
* we would like to use _filter_access_rules and override it on activities
model in order to be more standard;
* we would like to get rid of sudo used in various CRUD overrides as using
standard ORM method allows to correctly use current user;
* we would like to get rid of create_user_id field once we can keep the
current user as create_uid;
Access rights are a bit updated. They are now the following
* you can create activities for documents like posting messages (using
_mail_post_access attribute; if not defined, write access on document
is required);
* you can read activities for documents you can read;
* you can write and unlink activities either following the defined access
rule (created OR assigned), and otherwise like posting messages (
using _mail_post_access attribute; if not defined, write access on
document is required);
In this commit we also hide edit / mark as done / cancel buttons for
activities the current user cannot modify.
This commit is linked to task ID 1856417 and PR #27619.
Co-Authored-By: Sébastien Theys <seb@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
When a record inaccessible by the user is linked
to a message in a channel accessible to the user,
Avoid to raise an access error due to this linked record.
Also need an aditional query in test query_count.
closesodoo/odoo#28312
Commit 356a421660 introduced a hook to avoid sending emails while
installing application data. However we have to carefully re-activate email
sending in tests that depend on them especially performance tests.
This commit also update performance counters to match the current state of
counters as it was not totally updated.
Commit linked to task ID 1902307.
When sending notifications by batch one notification email can be send
up to 50 people. For one mail_mail entry to handle 50 emails can be sent
as those are sent independently for each recipient.
In some cases a bounce may occur while the whole batch of recipients is
not completely mailed. In that case the mailgateway will update the
notification status to bounced. When the cron finishes to send the whole
batch of emails it tries to update the notifications of all recipients.
However as a notification has already been updated due to the bounce we
face a concurrent update, meaning the transaction is rollbacked.
Emails have been sent but notifications are not considered as sent as they
have not been updated accordingly. Next time the cron runs it will send the
same batch again, with probably the same bounce and rollback. We could
therefore face an email loop.
This commit fixes that by setting notifications to a transient exception
state. Notifications are locked, meaning bounced will have to wait for the
transaction to finish before updating them. That way the cron can run
safely on the whole batch and we avoid having emails loop. It has an impact
on query count as a search and write is performed in the send process.
This commit is linked to task ID 1893054. Done in collaboration with
@Xavier-Do .
Before this fix the creation of task assigned to admin was leading
to the creation of mails.
This is a generic fix to avoid to notifiy a user when he is add as a
follower when creating data from odoo data files.
closesodoo/odoo#27682
This is done by adding a new field on mail.thread objects and setting it when posting a message with attachments on a model inheriting from mail.thread.
Was part of PR #26740
Was part of task #1880089
This commit is related to enterprise commit that replaced mail_push.
It is about:
[MOV] ocn_client: Odoo Cloud Notification for mobile push notifications
odoo/enterprise@7587be4663
Indeed counters are impacted by code located in enterprise because
those are "maximum queries" counters.
As ocn_client is an auto-install module enterprise runbot would
be broken if the counters weren't updated.
-remove margin
With the spirit of making tests determinists,
we can remove margins to have a real test of query count.
-mock random on assert query count
bus gc is triggered using random. Therefore, when send_many is called,
we have 1% chance to have more query. Mocking random.random to 1
will disable gc during query count tests (not during warmup).
Could be interresting to put gc collection in a cron latter
-add more info on querycount
Adding file and line number on query count failure/info will help to update
the query counts.
-update query count based on enterprise
Update all query count with enterprise values (exactly)
-normalize query counts with enterprise
voip module add a read on activity type (during create) in enterprise,
leading to one more query but also more information in cache.
Therefore, the next assertion will need one more query to access this data
in community.
Adding an access to activity type in the first assertion will allow
to have the same cache state in community and enterprise.
Task: #1878588
PR: #26476
Update the query count to avoid the runbot to be randomly red
Temporary fix!!!!! Will need to check with in details what is the
cause of this.
Those are the changes for the second part of test
Purpose of this merge is to improve onboarding of Discuss. This is done via
a wow effect and a bot to test the Discuss app; otherwise you have nobody to
talk to. Purpose is also to improve retention as "the best way to increase
retention is this: when the user invites someone, when this guy activates its
account, the user gets a push notification from the invited user that just
logged in; that way he will come back to Odoo and start discussing with its
colleagues.
Concerning your new best friend: it is not a dog but Odoobot.
See sub commits for more details. This merge is linked to task ID 1838588 and
closes PR #25075.
Purpose of this commit is to improve onboarding with a wow effect and a bot
to test the Discuss app. Otherwise new users have nobody to talk to. Retention
will be improved by both increasing interactions and onboarding of Discuss
features.
This commit adds a simple bot in discuss. It answers some questions, helps
users getting their hand on discuss and eases the onboarding.
In this version, the flow is quite simple, and only im_livechat adds some
logic in order to show canned response. The logic is contained in new
modules: mail_bot and im_livechat_mail_bot in order to keep everything
well separated. It also allows users to remove the mailbot if they do not
want to keep this functionality.
Odoobot will only answer if he is in the onboarding conversation (alone
with a user in a channel of type chat) or if a user pings odoobot.
Odoobot logic applies to both standard chatter / channel messages and
also transient messages (like help commands).
Specifications
* 2 minutes after first sign in, users will receive a direct chat from
Odoobot;
* make Odoobot an archived partner;
* scenario
* Odoobot: "Hello, I'm here to help you discover chat features. Try
answering me with an emoji :)";
* User: Send emoji
* Odoobot: "Great! :) Did you notice that you can also send attachments,
like a picture of your cute dog? Try it!"
* Odoobot: "Not a cute dog, but you get it :) To access special features,
start your sentence with "/" (I.E. /help)""
* User: /help
* Auto message then Odoobot: "Wow you're a natural! As a channel usually
contain a lot of users, you can grab the attention with a ping. Try to
ping me with @Odoobot!"
* User: @Odoobot lorem ipsum
* if Livechat installed
* add 2 demo canned response so it does not look weird (like "Hello, how
may I help you?" and "Have a nice day!")
* Odoobot: "Perfect! <br> Try to type ":" to use canned responses."
* User tries canned
* Odoobot: "Good, you can customize your canned responses in the live chat
application. <br><br> + réponse suivante"
* Odoobot: "There's 3 different ways in Odoo to interact with your
colleagues: via this chat window, [img of chat window] via the Discuss
application [img of Discuss app + icon on it] or via the chatter [img of
the chatter]. Aaaaand that's it! Enjoy discovering Odoo! :)"
* random answers to ping/bad answer
* "Mmmmh I'm not sure what you mean.. Can you try again?"
* "I'm afraid I don't understand. Sorry!"
* when someone pings @OdooBot with no reason: Odoobot: Yaaaay that's me!
[party emoji]
* fun stuff to add for some answer
* User: i love you / love
* Odoobot: Aaaaaw that's really cute but, you know, bots don't work
that way. You're too human for me! Let's keep it professional <3
* User: Fuck
* Odoobot: That's not a really nice thing to say, you know? I'm a bot but I
have feelings, ok?! </3
This commit is linked to task ID 1838588 and PR #25075.
We do not want inactive partners to be added as followers. Indeed this may
lead to unwanted notifications send as inactive partners are not easily
found in the various widgets. It also creates unnecessary data and
computation.
This commit has a small impact on performances as we choose to do it in
message_ subscribe method. Private _message_method is left untouched as
parameters given to this method are left to caller control.
This commit is linked to task ID 1838588.
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit cleans code about sending email notification to recipients.
Purpose of this code is to prepare notification emails, group recipients
and finally send emails. In this commit we clean and optimize a bit by
* propagating some additional parameter to simplify code, like record
on which the notification process runs;
* inlining some code currently located in sub-methods. It eases code
understanding as there are less code jumps. As those methods are not
inherited inlining them can be done;
* simplifying a bit notification emails preparation and computation;
It allows to save a few query by avoiding to fetch and browse again some
data that were already computed.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit is related to enterprise commit that updated mail_push. It is about
[REF] mail_push: optimize mail.message notification process override
It updates code of mail_push to lessen its impact on mail-related code. It
allows to change a few counters in test_mail. Indeed counters are impacted
by code located in enterprise because those are "maximum queries" counters.
As mail_push is an auto-install module enterprise runbot would be broken
if the counters weren't updated.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
In this commit we update _notify method of mail.message to fetch most data
related to notification process in a single query. Indeed posting a
message can be a costly process, especially when involving several partners,
channels, depending on their notification status, user groups, ... Most
of the required data can be fetched in a single hand-tuned query.
Purpose is to lessen query count. Side effect of this commit is that code
is less recordset based and therefore more low-level. It is also harder to
customize the behavior through inheritance as it implies rewriting a bit
more of code.
This query is located in a private method on follower model. It takes
parameters allowing to either fetch data related to followers of a given
subtype, either related to some partners and channels. First use case is
related to the process of posting a message with a subtype that triggers
notification of followers. Second use case is related to notifying some
specific partners or channels of a given message. It takes notably into
consideration internal subtypes and active field of partners, allowing to
correctly handle corner case for deactivated followers and portal / share
partners.
Notification process is divided into two steps. First one is to compute
recipient data. Second one is to apply the result of this computation and
call the various notification mechanisms accordingly. Doing so allows to
easily re-call notification process or compute some data differently
if necessary.
API of notification methods is updated to allow passing notably the values
used to create the newly-posted message. It allows in some simple case to
avoid browsing message and partners when no notification is necessary. It
saves some queries in simple case like posting messages with specific
subtypes not often followed or logging notes without mentioning people.
This commit allows to save a few queries on several performance tests as
indicated by updated performance counters. Future commits will gradually
propagate the use of this data to further lessen query count.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
Purpose of this commit is to speedup tracking values creation by manually
creating them using the newly-introduced multi create. As tracking values
creation is already done manually as sudo when creating mail message we
just update the code to directly insert them as multi.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
Commit 896e36edab added support of multi insertions when creating new
records. This had a great impact on mail-related tests involving several
followers update. This commit updates the counters to match the current
runbot state on master.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual forward port of commit 69714fbeee
done in saas-11.2.
Previously to this commit needaction used by JS was not taking into account
read notifications. It means notably Inbox counter could be higher than
expected as taking into account read messages while Inbox displays only
unread messages. This commit fixes that by checking notification state when
giving needaction_partner_ids to message_format result.
This fix has a small impact on performances as message_format is used in
notification process for chat or push. A better implementation of message
format and its postprocess could probably lessen this fix impact. As we
target stable version we avoid rewriting other part of the code. Optimization
will be done in development version.
Related to task ID 1841243. This is a manual forward-port of commit 69714fbeee
done in saas-11.2.
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.
Purpose is to lessen query count by avoiding to browse and/or fetch data when
not necessary. This commit does two main things
* first one is to avoid checking for existing statistics in mass_mailing
where only checking existing of a mass_mailing on a mail to send is
sufficient. It allows to avoid fetching data from statistics table;
* second one is to rewrite part of the post_process code called after sending
emails. Using list comprehension and mailing_id existence on mail_mail
allows to save several queries on standard post flows;
Most tests benefit from this code update. On overall community runbot about
3K queries are saved with those small optimizations.
mail_push module in enterprise was adding too much extra queries. mail_push
being auto-install in enterprise mail performance tests were done with its
overhead taken into account. Commit done in enterprise cleaned a bit the code
to lessen mail_push impact allowing to lessen some top counters. Community
runbot counters are now nearer enterprise-based counters.
This commit is related to enterprise commit https://github.com/odoo/enterprise/commit/0a3ba658f18e03fd76caba86cba7be32d047f0a9 .
Xavier-Do