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
Correctly use the email_from tag from template.
This partially reverts commit 0f82346167.
"[FIX] email_template: keep email_from and outgoing server"
Remove the email_from part that was incorrect, keeping the one on mail_server_id
Instead of assigning an non-evaulated email_from in the context, specify the
email_from in the onchange method. This way the created email has an evaulated
from value. This was an issue for templates using email_from like
"${(object.user_id.email or '')|safe}"
In the _notify method method, the email_from is partially respected as it will
be used a fallback only. However changing that would introduce a modification of
behaviour not suitable for 7.0 branch.
Fixes#8409
The commit 312b85e added a reloading of the chatter messages after
closing the mail composer. But e.g in Messaging > Inbox a simple reload
isn't enough. For now this commit restrict the reload to chatter logs
(e.g the chatter of a quotation).
related to PR #7596
Always reload the message after the mail composer message is closed.
Since there is several unrelated model it would probably messy to go
from the mail thread to the mail composer popup to see if a new message
is posted (or get it and add it in the chatter like done in the simple
message editor).
With this change, anytime the mail composer modal is closed the mail
thread messages are reloaded.
closes#7596
opw-644406
When sending an email from mail.compose.message using a template, the system
should use the outgoing mail server associated to the template.
Introduce context hack to keep these values.
This should NOT to be forward ported to version 8 where a proper fix exists.
Fixes#3848
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
As of version 8.0, search_count method has been implemented
Usage in this place is not needed though,
as we just need to know if there are messages in domain,
not the exact number of them.
Due to that we replace method search_count with search and add a limit of 1,
which provides better performances.
Fixes#6670Closes#6679
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.