By default in the notification manager we see something like:
```
record name {a second ago}
summary V
```
but if for example the record name is long or the summary empty, we can
have something like:
```
record name so very long {a s}
V
---
record name so very very lo...
V
```
This is because the record name was not allowed to grow, and the
positionning of the check mark based itself on the existence of the
summary container (.o_last_message_preview).
With this change the date a message was sent is shown in any case and
the check mark is on the right.
opw-1911654
closes#28960
When we mention for example `@hell'o`, the user will be added as
subscriber but he is not linked.
This is because there is two part of mentions:
- inserting the mention in the message: at this point the mention is
not escaped (only space are replaced with non-breaking space).
- wrapping a link around the mention in a message that is being posted:
at this time the message has been escaped ( for &<>"`' ).
Thus when wrapping the mention, we have to search the escaped content.
In the case of canned response, the system is different with defined
substitution that replaced the "shortcut" so this makes no change to
that.
Added test without fix failed with:
8. should contain a link in the message content (expected:1, result:0)
9. should have correct mention link in the message content
(expected:"@ЅpëciãlUser<&>\"`' ツ", result: "")
opw-1909300
closes#28846
Have a user A having the focus on the search bar, minding his own business
Have a user B send a direct message to user A
Before this commit, the chat window on user A's browser took the focus manu militari
After this commit, the focus stays on user A's search bar
OPW 1911553
closesodoo/odoo#28915
In the extended composer, we focus on subject when adding a mention in
the body. Focusing in subject is wanted at the opening of the composer,
but not when adding a mention.
opw-1911566
closes#28910
Before this commit, we had the following issue:
1. Open two tabs A & B.
2. Receive a message from a channel in tab A.
3. Mark it as read in tab A by clicking on the
chat window of the channel.
> The unread counter is correct in tab A: no
unread messages on this channel, and the
messaging menu counter has been updated.
> The unread counter is not correct in tab B:
it still has unread messages on this channel,
and the messaging menu counter has not been
updated.
The issue was caused by not notifying the updated
unread counter to the widgets when receiving the
'channel_seen' notification from the longpoll.
It was working in tab A because this is were we made
the action, so that it already marked messages as
read without waiting for the longpoll response.
However, Tab B has to wait for the longpoll response
to update the unread counter. It was updating the
counter, but it was not notifying the widgets.
This commit fixes the issue by letting the widgets
know when the unread counter has been reset.
Task-ID 1911239
closesodoo/odoo#28833
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
Revision on https://github.com/odoo/odoo/commit/299ebb2cdf63de2e3967da0d2f3e7effd239812b
The commit above added the notion of moderation, which
requires re-rendering the thread when a message has its
moderation changed (i.e. the message is deleted on reject
or is no longer marked as 'pending moderation').
However, this condition was triggered even when the
moderation status on the message has not changed.
This introduced a crash when using the search in discuss:
- Access a channel with more than 30 messages, so that
not all messages have been fetched.
- Search messages in this thread so that it displays more
than 30 messages, and the last message of those has already
been fetched.
> It crashes with "Cannot read property 'getID' of undefined".
The bug comes from re-fetching messages: it behaves as a
"load more" fetch, although no message has been stored yet.
A "load more" fetch requires at least one message in order to
determine the minimum message ID to fetch, thus the crash due
to having no message to get such an ID.
Here's the explanation why it fetches with load more:
when performing the search and fetching the same last message,
it will detect that it has already been fetched. Its moderation
status is 'accepted', and it will assume a change of moderation
status. This will trigger a fetch and render of the thread.
At this moment, if the search exceeds the fetch limit, not all
messages will be fetched, so that this fetch is considered as a
"load more" fetch.
This commit fixes the issue by only re-rendering the thread
when there is a change of the moderation status on an already
fetched message. Since changes of the moderation status are
handled by means of the longpolling, it should be rare to run
into the case of having a change of moderation status on a
message while using the search on a thread.
Task-ID 1910180
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
The commit above consisted of refactoring the JS mail module.
A small regression was introduced on messages linked to a document
from a chat window: it was no longer displaying the link to redirect
to the document that this message originates from. This issue was
only isolated to chat windows: it was working fine in the Discuss app.
This commit re-introduces the displaying of the document link on
messages from chat windows.
Task-ID 1910119
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Resulting of the mail JS refactoring, the list of prefetched suggestions
has been changed as follow:
- before: list of list of mention suggestions `{Array<Object[]>}`
- after: list of mention suggestions `{Object[]}`
The change resulted in wrongly thinking that wrapping the list of
suggestions in a list was pointless, thus simplifying it as a simple
list of mention suggestions.
However, because of this change, it has become much harder to
mention employees and followers of documents from the chatter:
it now always fetches all partner suggestions at all time, whereas
before it was suggesting followers, then employees, and finally all
partners based on the input of the user.
In fact, there was a purpose of using a list of list of prefetched
mention suggestions, which is to group suggestions by "priority":
followers first, then employees, and all partners as a last resort.
This commit re-introduces prefetched mention suggestions as a list
of list of partners, so that it re-becomes easier to mention
followers and partners of a document from the chatter.
Task-ID 1910111
- 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
Revision on https://github.com/odoo/odoo/commit/5f8d3c61bee40d027efc5041cdc4bca5e67c42d7
Before this commit, there was a traceback when you had two needaction
notifications related to the same document.
This is caused by a typo in the commit above: the object `similarItem`
has a property `messageIDs`, but the code wrongly access the property
`messagesIDs` (see the extra "s").
Steps to reproduce:
- Set notification management to 'Handle with Odoo' for Admin
- Demo mention Admin twice on a specific project task
- Admin opens messaging menu
Display error `Cannot read property 'concat' of undefined`
Issue reported on this PR comment: https://github.com/odoo/odoo/pull/28462#pullrequestreview-175001349
Task-ID 1909521
closesodoo/odoo#28703
- 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
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
11.0 backport of 12.0 #28474
issue found when checking opw-1904029
closes#28506
Before this commit, when there was several previews
on the messaging menu that were not linked to any
document, marking one of them as read had the unintended
behaviour to mark all of them as read.
Steps to reproduce:
- Admin with notification management as 'Handle with Odoo'
- Demo assign Admin to two different tasks
- Admin mark one preview as read
> Both previews notifying assignment to a task have been
marked as read
This is caused by the fact that messages of those previews
are not related to any document. As a result, when marking
one preview as read, it maps related messages to mark as
read, which was taking into account all messages that are
not related to any document.
With this commit, previews now tracks message IDs, so that
marking one preview as read only mark the related messages
as read.
Task-ID 1907159
Before this commit, when the user clicked on a preview in the systray
messaging menu that is not linked to any document, there was a
traceback.
Steps to reproduce:
- Admin sets notification management to "Handle with Odoo"
- Demo user assigns Admin to a task
- Admin clicks on preview from being assigned to a task
Those are previews from notifications received from the inbox,
which are not related to any document. It attempts to open a
document that does not exists (i.e. no model/id).
With this commit, when such a preview is not linked to any
document, it now opens Discuss with Inbox.
Task-ID 1891350
Backport of 17bb0ca443
Before this commit, the user could not receive any notification
from the chatter of a document when having Notification Management
set to "Handle with Odoo".
This problem occurs when the user opens (or has opened) the document.
Any messages received from the document are automatically marked
as read, so it removes the notification right after receiving it.
In order to no longer have this issue, the user had to reload all
pages that have opened this document.
This commit slightly changes the behaviour of the chatter, so that
it automatically marks it as read only when accessing the document,
but not when the document is open (or has been opened). Consequently,
if the user has opened the document and then receives a notification
from this document, it won't automatically mark it as read.
Task-ID 1895359
opw-1890556
closesodoo/odoo#28113
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
Spamming the "send" button on the chatter send multiple times the
same message. This PR simply disable the send button to fordib the
spam.
opw-1895511
closes#27233closesodoo/odoo#28078
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
In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
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
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
On mobile (specifically in landscape orientation as the height of the
viewport is narrower), the content appear over the bottom toolbar
instead of going below.
Solution is in 2 parts:
* raise the toolbar way above the content
* make the toolbar opaque
closesodoo/odoo#28429
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
Christophe Simonis