If the "NEW MESSAGE" or "Log an internal note" are clicked succeedingly
too fast, we can get into a situation where the composer is init'ed but
have not already been start'ed.
closes#11952
opw-675973
In Discuss, if a message was selected as message to reply to, it wasn't reset
when switching to another channel. So if the user sent a message in that other
channel, the message was sent as reply to the previously selected message.
This rev. ensures to always unselect messages when switching between channels.
Closes#11879
Rev. 56cec604e6 modifies
the auto-commit behavior of the mail queue scheduler,
to allow using it within tests.
The condition was wrong and always True as soon as
the registry was loaded, permanently disabling
auto-commit, both during tests and outside tests.
This broke the duplicate emails protection.
When a user is subscribed to a channel with many messages,
the discuss initial rpc /mail/client_action can become very
slow (in production, the rpc took > 20s when subscribed to
the Community mailing list). This is due to the query in
_get_message_unread, counting the number of unread messages.
This commit adds an index on the relation mail_channel_partner,
this allows postgres to perform only index lookups, and speeds
up the query by 2 order of magnitudes.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
Before showing a chat notification, a check is performed to ensure that the browser does support
notifications. On browsers that do not support Notification (IE, android native,...), the check was wrong and
would eventually cause a traceback. This will no longer happen.
- The "From" should not be the administrator user but
the postmaster/system, and should be an address that
ignores double-bounces. Using the default bounce
email accomplishes both.
- The "To" recipient should be the "envelope from"
sender when available, usually as provided by
the "Return-Path" header set by the upstream MTA.
If not present, fall back to the "From" of
the original email.
- adapt tests to verify the behavior wrt Return-Path
When an user sends an email from the chatter then quickly switch to
another record, it may happen that this.composer is already destroyed.
We prevent to display a traceback with this fix.
By default, users are supposed to be able to write messages
in threads only if they have the write access on the record.
This behavior is the behavior defined in Odoo 8.0.
This behavior can be changed by defining
`_mail_post_access` on the model,
to allow the creation of new messages
if the user has only the read access, for instance.
This is the case on `project.issue`, for instance.
Since 9.0, @ revision 88b8cd0587,
this behavior was broken: Any users having the read
access on the record was allowed to write messages in the thread,
while this should not be the case, except if
`_mail_post_access = 'read'`
has been defined on the model.
This is because the SQL query which is performed in order
to know the thread messages the user has been notified of
was expected to return only the ids of the notified message,
while it actually always returned all the message ids of the thread,
because of the LEFT JOINS, e.g.
```
LEFT JOIN "mail_message_res_partner_rel" partner_rel
ON partner_rel.mail_message_id = m.id AND partner_rel.res_partner_id = (%%s)
```
Instead of just checking the ids of the messages returned by this
query, it must check that one of the two columns
`partner_rel.res_partner_id` or `channel_partner.partner_id`
is filled, meaning the partner has been notified of the message or
is a member of the channel the message has been posted to.
opw-668589
The name of the static channels ('Inbox', 'Starred') are not translated
in the breadcrumb. The reason is that at intialization of the chat
manager, the translation are not yet loaded.
The fix is to use the lazy translate functionality, which applies the
translation when the string is displayed.
Courtesy of @aab-odoo
opw-673856
Otherwise recomputation may fail with "record does not exist or has been
deleted" when creating records with a value directly set for e.g.
'image_mediun' on a new product.
The issue comes from the storage of the images. When creating a product, the
creation of an attachment for storing the field `image_medium` triggers the
recomputation of that field before its dependency `image` is set. As `image`
is initially null, `image_medium` is recomputed as null, and this deletes the
attachment just created before the latter has completed its creation! As a
consequence, some code at the end of `create` for the attachment crashes
because the record has been deleted.
The following models have been fixed: `fleet.vehicle.model.brand`,
`hr.employee`, `im_livechat.channel`, `mail.channel`, `payment.acquirer`,
`pos.category`, `product.template`, `product.public.category`, `res.partner`.
opw 666330
Closes#11516
Aaron Bohy