Used case:
If you add a user which has no acces on a model(ex:purchase.order)
as follower on a record of this model. When someone responded by email on
this record, and when a message is sent on this record, an exception is raised
at the connection of the user added as a follower.
Fix:
To have the rights to read the message, a read notification for this follower must
be added to all parents of this message.
Closes#11902
opw:676699
With new api, this call is not wanted anymore. The cache is cleared
automatically, no need to clear the whole cache; that's a little bit
overkill and reduce performances.
This is a backport of commit 3d32e9966500290f35e6edfebf97b9a60a1fc495 done
in 9 and ported to the old API. The purpose is to avoid searching on
the res.partner table with a domain leaf being user_ids != False. Indeed
this search is costly. Use a direct search on the user table instead.
When sending a mail.mail with email_to, the processing split the email_to into
a list of addresses. However if the found addresses use the form name <email>
the name if lost in the process. A new email_split_and_format method is introduced
in tools and used to avoid loosing that information.
Mailing lists (mail.group) should not send specific notification emails.
Indeed there can be a lot of recipients and customizing each email can
take time to compute. This leads to posting a message on a mail.group
being very slow.
It is now possible for a model to customize the notification email
recipients computation. The first use is to ensure that mail.group
encodes recipients using email_to instead of recipients_ids. This way
less processing is performed on notification emails.
As stated in the comment:
```
all notified_partner_ids of the mail.message
have to be notified for the parented messages
```
Record rules are applied when browsing one2many fields.
Therefore, when browsing `message.notified_partner_ids`
with a user other than the SUPERUSER, the multi-company
rules are applied, and a regular user could therefore not see
all partners of the thread, according to which
company the partners are associated with.
Nevertheless, all partners of the thread have to be notified,
including the ones the regular user cannot see.
To reproduce the issue:
- Create a second company 'Second company'
- Create a third user, associated to the first company 'YourCompany'
- Set the demo user as in the 'Second company'
- Create a project 'test' in the first company, 'YourCompany'
- In the followers of the project, add the Demo user,
with as subtypes "Stages changes" only
- As the third user, create a new task in this project
- Change the stage of this task, as the third user [this is important]
- Sign in as the demo user, and see that you cannot access
your messages inbox, due to an access rights error.
opw-650563
Commit e0c1f54fd7 was supposed to prevent the message fetch in the
inbox view. However, self.is_log refers to the type of message: internal
note or message. This properly checks if the page displayed is the inbox
view before fetching the messages.
Related to #7596
opw-650208
Odoo Translation Bot
Goffin Simon
Nicolas Seinlet
Levent Karakas
Denis Ledoux
Thibault Delavallée
Julien Legros
Nicolas Martinelli
Christophe Simonis