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
Users subscribed to creation of records (new leads in a sales team, new
tasks in a project, etc.) are never notified. The reason is that users
were subscribed after the record creation notification.
Introduced in 43915a8721Closes#8723
It was allowed for all employees to read, create and edit
mail aliases. Only the deletion was prevented.
Nevertheless, giving the possibility to rename a mail alias
is allmost seen as a deletion, as you can rename it to something
that just won't be used anymore. Therefore, we can consider
to give any employees the rights to delete mail aliases.
Besides, not allowing the unlink leads to issues when the
mail alias is associated to a record the user wants to delete.
He was able to create the record, and its mail aliases, but
he could not remove the record, as he was not allowed to remove
the mail alias.
For instance, an HR officer was able to create a job position,
with its mail alias, but couldn't remove the job position he created.
Closes#8466