Fine-tuning of commit: d60f2ab0e2
Which applied when the next action was to create a new activity.
However the problem is also present when the next action is to send an email.
We extract the logic in a new private function to share the code in both cases.
opw 1904156
closesodoo/odoo#28819
- This commit prevent to send notifications to inactive users.
- This fixes a bug where two partners have been merged and one of its
users is archived.
If one of the two users is inactive the code might use its `notification
type` preferences instead of the active user's one.
closesodoo/odoo#28730
When a bounce is received, we look for matching partners in order to
increment the bounce counter. However by using [`ilike','email`] we carry
the risk of matching emails that contain the bounce email:
['email', 'ilike', 'john@hitmail.com´]
will also match 'random.john@hitmail.com' for example.
Using strict equality is safer, and the worst that can happen is that
we fail to count one bounce.
Fun fact: for the subscription model in odoo production database, the
get_activity_data rpc takes 36s, and transfer 420mb (non gzipped) of
data (when looking at all subscriptions).
The main reason for that is that the get_activity_data method create a
domain with all the res_ids (so, if you have 20k subscriptions, the
domain will look like (res_id, in, [...20k ids]). This domain is given
to read group, and the resulting groups (each with a domain key which
includes those res_ids) will be sent back to the web client.
As far as I can tell, the domain key is not used by the web client, so
we send (number of groups)*(number of records) of useless data.
This commit improves the situation in two different ways:
- we only generate the domain if there is a domain at the beginning.
This should greatly improve the performance when there is no current
domain
- we do not transfer the data to the web client
- If the `internal` field/column on the message subtypes (table: `mail_message_subtype`) is set to null instead of false in the
database, the notifications to the followers are not sent by mail.
closesodoo/odoo#28699
This is related to revision
71f188082f
This is nice to have a meaningful explanation
for the user to understand why his mail is not sent,
this is better to not interrupt the mail queue when doing so.
Because of the above revision,
when the mail queue iterated on a mail failing because
of an ASCII encoding issue,
the mail queue was interrupted,
and on the next cron call it failed again and again
on the same mail, therefore leading to the mail queue
to never be processed.
Fixes#27804
For the special case of is_blacklisted, and due to
the size of the tablers to handle, it's faster to
filter some records rather than searching the whole
res.partner table
closesodoo/odoo#28028
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
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
The CRON job that sends email sends them in a LIFO order instead
of a FIFO order which can lead to confusion when the order is
important.
Exemple, when updating multiple time an appointement, the last
update should be the newest mail clients receive in their mail box
which was not the case before this PR.
opw-1888601
closesodoo/odoo#27888
- When deleting attachments, the foreign key constraints on
`message_main_attachment_id` are triggered which could take
a lot of time to be computed.
closesodoo/odoo#28358
The objective of not creating the record if the email was invalid
was to avoid crash on import. But if the number of record created does not
match the number of record that would have been created (see in flush()
in models.py), this cannot work.
Also, it's necessary to tell the user that his import file has an error
and where. This is why a UserError must be returned.
Task ID 1902139
Closes PR #28011
Currently creating activities assigned to user not having to the document
raises an Error as people should not have activities they cannot handle
directly on a document they cannot access.
In some cases activities are created through business flow, like automatic
activities creation when creating leave requests. Assigning an activity
to someone that has no access to the document should not prevent from
creating the leave request.
This commit therefore does not check assigned user access on automated
activities to avoid having blocked business flows.
This commit is linked to task ID 1903484.
closesodoo/odoo#28139
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 .
The _search was already excluding these attachments but not the read_group
Avoid the read_group from mail to search on all existing attachments
Fixesodoo/odoo#27673closesodoo/odoo#27698
Before this commit, when a non-moderator user posts a message in a
moderated channel and refreshes the page, he could no longer see his
messages that are pending moderation.
Sending email to addresses containing unicode characters
cannot be parsed by python and result in a UnicodeEncodeError.
This PR catch that specific exception and output a meaningful
error message.
Decision has been taken to not trigger any error message
client-side has it would have needed modifications on some
sensitive low-level backend code.
To reproduce:
- Configure odoo so it uses an email server
- Send an invoice to a partner whoose email address contains
some unicode characters (exemple: æøåÇÀ@example.com)
opw-1892409
closesodoo/odoo#27804
Suppose user A creates a sale order S in company X. He then changes to company Y
Sales manager B, in company X, creates the invoice for sale order S.
Bug: the compilation of the report fails because of the user.name in the
template. Then the tracking update fails, making it impossible to validate the
invoice.
opw 1884915
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
Fix to commit: a1d6064dcc
Which erroneously put a mass_mailing method in mail,
as mail.mail.statistics is defined in mass_mailing.
Since it does not depend on the records, it been extracted from the
loop.
opw 1890461
closesodoo/odoo#27431
Purpose of this commit is to make search coherent with sanitize of emails
done when storing blacklist entries. We parse search terms in order to
find something related to email field and sanitize it to avoid issues
linked to case insensitivity or formatted addresses.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to correctly extract email address from the email
field of models inheriting from the blacklist mixin. Indeed email field
could contain a formatted address like "Raoul Grosbedon <RAOUL@example.com>".
Related blacklist entry would be raoul@example.com. We have to extract
the email from the email field and lowerize it in the SQL query or the
computation in order to have a fully working blacklist mixin. This fixes
some bits left at commit 2ff9b379ef.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
This commits fixes the use of email field in blacklist mixin as it was based
on 'email' field instead of the one coming from the _primary_email class
attribute since commit 2ff9b379ef.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Now that blacklist records are set as lower case be sure all checks in
blacklist are done accordingly by using the sanitizer before comparing
email adresses.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Currently blacklist is configured to have unique emails. Notably when creating
new entries it checks for existing records with same email to avoid crashing
about duplicate entries.
However it does not check if given values use unique emails. When importing
a big list of emails you are not sure emails are unique. This commit ensures
values given to create are correct to avoid crashing when importing a lot
of data.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to standardize content of blacklist records and
ensure only real email addresses are stored.
We introduce a sanitize method to extract email address from string (like
Raoul Grosbedon <raoul@example.com> -> raoul@example.com) and return a
lower case version of it.
Purpose is to gradually get rid of lower() that appear a lot in the code
and speedup computation by being sure everything is always lower case.
Moreover indexing on blacklist model will be more performant is using
directly email field content instead of having to lowerize it.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
The mail template mail_template_channel_send_guidelines should only be used
from send_guidelines action. Anyway, with mail_template on activity
and all demo done to show this mechanic on contacts,
trying to render this one will generate a traceback. This fix
transforms the mail_template to qweb view so that it won't be available in
mail template.
Purpose
=======
Remove the method 'render_template' in mail.compose.message as the indirection
is not useful. Call the method on the correct model (mail.template) directly.
As building a custom filter on 'Blacklist is false' is creating a filter '!= True'
instead of '= False', the assumption that operator must always be '=' is wrong.
This commit inverts the value and operator if the operator is '!='.
Fix for Task ID 33224
PR #27334
Several quick fixes:
- repair malformed SQL queries and injection problems
- proper token comparisons (consteq)
- better translatable terms (less context-lessplaceholders)
- basic testing of case-(in)sensitivity of blacklist
- safety check for non-implemented cases in search methods for computed
field
More testing and review is needed for case-sensitivity and email
extraction from generic "addressing fields".
Christophe Simonis