Before this commit, when clicking on the activity view icon
from an item in the systray activity menu, the activity view
had no search filter by default.
This commit now auto-select 'My Activities' in the activity
view when redirected from the systray activity menu.
closesodoo/odoo#30702
Before this commit, clicking on an item from the
emoji menu of a composer was not putting the emoji
in the input.
Steps to reproduce:
- Open discuss app
- Select a conversation with a composer
- click on emoji menu in the right-side of the composer
- click on an emoji in the emoji menu
> the emoji has not been put in the input of the composer
This problem was caused by a race condition with the event
`focusout` on the emoji button and the `click` on an emoji
item. `focusout` always happens before `click`, and `click`
event following a `focusout` event can only happen when the
element is visible. This was not the case, because the emoji
container is removed from the `focusout`, so no `click` is
triggered on the emoji item.
This commit fixes the issue by listening on `mousedown` on
the emoji item instead of `click`, which is triggered before
`focusout`.
closesodoo/odoo#30694
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
to ControlPanel/Search view refactoring.
*: mail,sale,web_diagram
The ControlPanel being now inside the DOM of views' controller,
those existing widgets needed to be adapted (in the way they define
if and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
to ControlPanel/Search view refactoring.
The ControlPanel being now inside the DOM of client actions, those
existing widgets needed to be adapted (in the way they define if
and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Moved the field 'active', 'res_model_name' and 'thumbnail' from
ir.attachment to enterprise's documents.document.
Moved the pdf split feature to enterprise's Documents module.
task: #1908896
This commit adds the seen icon next to a message for all channels
except livechat.
It tracks received and seen messages for all members of the channel.
Icon is either 1 or 2 check(s) ('v' or 'vv').
Those are the different states of this 'seen' icon:
ICON: DESCRIPTION:
no check .................. no one has received the message.
1 check ................... some members have received the
message, no one has seen it.
2 checks (greyed-out) ..... some members have seen the message,
some or everyone has received it
2 checks (green) .......... all members have seen the message
This icon is not shown for messages preceding the last message seen
by everyone, in order to reduce visual noise.
Task-ID 1881001
This commit adds the possibility to customize the name
of a DM conversation. To do so, click on the gear icon
when hovering on a DM in the discuss sidebar.
This feature intentionally removes the access to the
settings of a DM, because the settings view only makes
sense for non-DM conversations.
Task-ID 1881001
Before this commit, when selecting an emoji from the composer,
the emoji was put at the end of the composer content.
With this commit, the selected emoji is now put in the composer
based on the position of the cursor. It also focuses the input
and set the cursor just after the newly inserted emoji.
Task-ID 1881001
Discuss sidebar now has a single category for public and
private channels called "Channels". Private channels are
prefixed with a keylock icon.
Task-ID 1881001
With this commit, the UI for "is typing..." notifications
has changed.
** before **:
In Discuss & chat windows, "is typing..." notification bar
at the bottom of the thread, inside the conversation.
** after **
In chat windows, animated '...' next to conversation name.
In Discuss, animated '...' next to conversation name in sidebar,
and text below the composer.
Task-ID 1881001
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 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
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
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
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, you could only access the activity view of the
Contacts app via the activity icon in activity systray menu.
With this commit, all apps in the activity systray menu that support
the activity view now have this icon that redirects to the
corresponding activity view.
Also, the icon in the activity systray menu has been changed in order
to match the icon of the activity view in the view switcher.
Task-ID 1894900
closesodoo/odoo#28066
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
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
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, 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
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
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
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
Alexandre Kühn