Before this commit, the process of positioning chat windows
could fail if one of the tabs had discuss open.
When a chat window was hidden and become visible, the algorithm
was not updating the state of the chat window to "visible" when
discuss was open. As a result, it was always trying to make it
visible, resulting in an infinite loop and raising the following
error message:
`Uncaught RangeError: Maximum call stack size exceeded`
This commit ensures it works even when discuss is open.
opw-1919327
closesodoo/odoo#30137
opw-1921686
The failed mail notification group all the records of the same
model that failed to send an email.
Before this commit, the failed mail notification displayed as
title the name of the last record that failed to send an email.
Now, the notification displays as title the model name.
closesodoo/odoo#30134
In 12.0 commit f2302dfb2 the method openDmWindow was renamed
openDMChatWindowFromBlankThreadWindow but it called openDmWindow at one
location which caused click on user connection notification to cause an
error instead of opening a chat window.
opw-1910521
closes#30084
rST is somewhat unforgiving when it comes to whitespace. The extra
indentation on list would generate (nested) blockquotes instead of
just paragraphs & list items, and the missing empty lines would make
rST parse the entire block as a single paragraph rather than a
paragraph followed by a list.
closesodoo/odoo#30058
The information of the active model and record was not given in the context
Records created from the Manage Messages and Manage Attachements in the debug
menu were not linked to the current records
Add context in test too
closesodoo/odoo#27766
When sending a message through the chatter, the user context (including
the language) is not sent to the server. This causes issues to render
the mail templates in the appropriate language.
closesodoo/odoo#29422
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Before this commit, when receiving a new message from a new DM
or livechat, the newly opened chat window was automatically
focused and marking messages as read.
Chat windows that are automatically opened without any user
interaction, such as when receiving a new message from a chat,
should not be focused. Those chat windows are "passive", and
the user must click on them in order to have focus and mark
messages as read (the chat window is no longer passive as a
result). The bug has been introduced by the refactoring from
the commit above.
In fact, there was a very short period of time during which the
chat window was passive. However, due to the way chat window
server-side state synchronization works, the chat window was
automatically closed then re-opened. This resulted in some visual
flickering of the chat window ('open' > 'close' > 'open'), and
the conversation was automatically marked as read. This was a
consequence of the actions 'open' > 'close' > 'open' that removed
the passive property of the chat window.
Chat window server-side synchronization relies on a notification
that tells the state of the conversation. Due to bad design, this
notification had exactly the same format as the one for notifying
all browser tabs of a newly joined conversation.
This commit fixes the issue by distinguishing "channel join"
and "chat window state" notification, so that the former is not
treated as a chat window notification. It fixes the problem
because it was precisely the "channel join" notification that caused
the chat window to close and loose its passive property.
Task-ID 1914735
opw-1914371
closesodoo/odoo#29223
When selecting a mention we will add a mention in a list of selection
from the list of mention.
In 10f0766b3 that mention in list of selection was escaped so this would
match the text that would be escaped when the mention was searched in
it.
But the object are the same so the change modified the original list.
Modified test failed with:
```
10. first partner mention should still display the correct partner
name (Expected: "ЅpëciãlUser<&>\"`' ツ" Result:
"ЅpëciãlUser<&>\"`' <&>"`' ツ")
```
opw-1909300
closes#29098
Before this commit, the total amount of unread messages of a
channel was considered in the computation of the messaging
menu counter.
As a result, if the channel contains 100 unread messages,
the messaging menu was displaying a counter of more than 100.
The intended behaviour is to increment the messaging menu
counter once per unread channel, thus the example above should
incremented the counter only once. The channel preview itself
should still display that there are 100 unread messages.
Task-ID 1913080
closesodoo/odoo#29080
This tour was broken since the following refactoring:
https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
With this commit, mail_tour should work correctly, and
is automatically run on runbot.
Note that the tour is automatically run in the module `test_mail`,
so that the tips are not displayed by installing Discuss.
Task-ID 1912730
closesodoo/odoo#29040
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Before the commit above, it was possible to reply to a message
from Inbox. Those messages were linked to a document, and replying
to any of them put a response in the related document.
This feature has been broken since the commit above: the reply
icon was only shown on messages linked to a channel, instead of
message linked to a document. Also, it was erroneously prompting
that the message was sent to the channel, even though it was not
the case.
This commit fixes the issue by toggling the visibility of the
reply icon, so that it is shown only for messages that come from
a document. Also, since posting a message requires a thread, this
commit added the possibility to post a message from a mailbox,
which instead posts the message to the related document thread.
Task-ID 1912647
closesodoo/odoo#29028
This commit fixes two related issues:
1. Previews without any message should not be dated.
Before this commit, when a channel or dm preview had no date,
it was displaying the current date. This commit fixes the issue
by not showing the date for those previews.
2. Dates previews should appear before undated previews.
Before this commit, undated previews were considered similarly
as dated previews in the ordering of previews in the messaging
menu. Since DMs are shown before Channels, any pinned DM without
any message were displayed on top of messages with some message.
This commit fixes the issue by putting undated previews after
dated ones. This rule is applied before considering type of the
thread (i.e. DMs before channels).
Task-ID 1912001
Before this commit, DMs had the prefix '#' in their
displayed name (e.g. '#Demo User').
This commit fixes the issue by putting this prefix
only on non-chat DMs. In particular, mailboxes, DMs
and Livechats no longer show this prefix. This change
is also visible in the breadcrumb of the discuss app.
Task-ID 1911738
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
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
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
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
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
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
This widget claims to support one2many fields but it doesn't work in most cases.
This was triggering warnings when this widget was set on another field or in another
view (i.e. in Studio).
opw-1905803
closesodoo/odoo#28413
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#28114
Before this commit, text color was in grey because of a css
inherited rule applied by Bootstrap when there is no href attribute.
In mobile, text color was in white as the background and it was not
possible to see the text.
Now, we transform this link into button to restore the previous
behavior and keep it visible in mobile.
closesodoo/odoo#28061
Before this commit, there may be a silent crash when accessing the
livechat from the customer URL, e.g.
`http://mycompany.odoo.com/im_livechat/support/1`.
This issue occurs when bootstrap popover lib is not available.
This does not occur if one tab of the current browser has this lib
loaded. To reproduce this issue, open the customer URL from another
browser:
1. Access to `/web` from any browser (e.g. Chrome)
2. Go to Live Chat app
3. Select a livechat channel
4. Go to sheet page "Widget"
5. Copy text of the customer URL (2nd "Copy Text")
6. Paste the URL in a different browser (e.g. Firefox)
7. Open the livechat menu
8. Inspect dev tools
=> It will complain that `popover` is not a function.
We would like to keep the livechat lib as small as possible,
so instead of importing the boostrap lib, we simply prevent
the logic that generates the issue.
Task-ID 1885445
Before this commit, there was the following issue
in the chatter:
- on document with customer field set;
- open the composer;
- post a message with suggested partner checkbox set;
=> the partner is not added as a follower of the document
This was caused by a typo when refactoring the JS of the
module mail.
Task-ID 1896010
Closes#27864closesodoo/odoo#27932
Since rev. 755a8d815a, it crashed when the user tried to open an
x2many record in form view (thus in a dialog), if there was a
chatter in that form's arch.
This was because the wrong viewType was used (for instance, list
or kanban instead of form), to look into fieldsInfo, and thus the
chatter fields couldn't be found.
opw 1891378
opw 1892520
opw 1893100
closesodoo/odoo#27844
There was two issues with the previous code:
1. It was using a weak heuristic to determine whether the
current thread is a channel (ID is a number)
2. For any channel, it was always passing `moderated_channel_ids`
with some values to the server, even though the channel
is not moderated at all.
This commit solves both issues by passing `moderated_channel_ids`
only for moderated channel. Also, this logic has been moved from
SearchableThread to Channel, since moderation makes only sense for
channels and channels are aware of whether they are moderated or
not.
Before this commit, a moderator of a moderated channel could see
commands on 'pending moderation' messages in a chat window, although
none of them work in chat windows.
Those commands only work in Discuss. Making them work in chat windows
is not trivial, because some code must be redesigned for this.
This commit disables moderation commands in chat window. Moderators
of such channel now see 'Pending moderation' on such messages in
chat window, and mouse-hovering on this annotation tells the user
to moderate those messages in the Discuss app.
Task-ID 1887963
Alexandre Kühn