Before this commit, when we post a message and someone
has received it, there could be a traceback.
Steps to reproduce:
1. Two users are logged in.
2. On one user:
- open any app except Discuss
- From systray messaging menu, click on "New messages"
- Open Discuss
- Post a message in a direct chat with other User.
> traceback `Cannot read property 'getID' of null`
closesodoo/odoo#31228
We want to avoid that a `setTimeout` started in one test has an impact on other
tests. This is especially true with the status update loop. Since mail_service
is used in multiple tests, the safest solution is to patch timeouts everytime
we make a call to getMailServices.
There is no need for an unpatch, the patch become the default behaviour until
the page is refresh at the end of tests.
It is possible to manually add the patch after calling `getMailServices`
```
this.services = mailTestUtils.getMailServices(this);
this.timeoutMock = mailTestUtils.patchMailTimeouts();
```
This can be usefull if we want to get the timeoutMock to simulate time changes.
Task: 1856205
This commit is a refactoring of im_status management.
This commit also add im_status in two places, near the author in a mail thread and on each suggestion when using mentions.
A service to manage im_status will have multiple benefits here:
-centralise information, avoid to call the server multiple time for the same im_status
-update all im_status at once and keep consistency in display.
With this commit, the im_status updates are now done by rpc call.
Updates where previously made with the bus but this has some drawback,
since the bus will only give the information 50 seconds after the beginning of
the request, in the worst case, we van wait 2*50 seconds to get an update.
More than that, the im_status where only updates for pinned dm_chat. Dm chat
are synchronized cross tabs, making the use of the bus possible for this purpose.
Since we will need to display im_status not linked to dm_chat, the list to update
will be different from tab to tab making the use of bus difficult for this purpose.
Technical notes:
-im_search has been moved from bus to mail addons since it concerns mail.channel
-Update of an im_status should be reflected everywhere in the page.
Since im_status is a rendered template used in multiple widget, we should add
the correct logic to all concerened widget. The current solution is simple:
use a jquery selector to find every place where im_status is rendered.
-we add a new im_status: im_partner. This will indicate that that
the partner has no user linked to him, making it possible to avoid to ask
for status updates for this partner.
-The update will only be done when the tab is focused. (and will be done
asap once the tab get focus back)
Go on the crm activity view
Have your user operate in another language than en_US
Bafore this commit, the activity types were not translated
This was because the context was not passed to the function
After this commit, the terms are translated
OPW 1924232
closesodoo/odoo#30837
This is a regression from: 10f0766b3. In it the visual side was solved,
but unexpectedly the functional side still worked on unescaped content.
Thus visually a @partnèr could be seen as a link, but it was no anymore
added as follower.
Without change, modified test fails with:
mentioned partners are sent to server (expected: [1], result: [])
note: change is partial backport of 12.2 e2f20ffa9
opw-1931247
closes#30846
With the control panel refactoring, the auto_complete widget was set on
a different target, which caused issues with the search bar: the event
handlers for the search bar were triggered before the handlers for the
auto_complete widget.
With this commit, we make sure they are handled in the proper order.
Also, a small piece of code that was supposed to check the position of
the cursor was lost.
closesodoo/odoo#30795
Revision on https://github.com/odoo/odoo/commit/0d87b1ccea07b952d9079008cfa3cddaf1ccdbee
The commit above prevents opening a chat window when we do not have
access to messages of the conversation. This may happen when
receiving a notification from a document we do not have access
rights.
However, the changes in the code above has an unintended side-effect
of opening a chat window twice when clicking on a channel preview
from the systray messaging menu.
This happens because when clicking on a preview, it detaches the
thread and opens the chat window. Meanwhile, there is a RPC to
notify that the chat window is detached, and the new window state of
the channel is received on the longpolling. Two concurrent attempts
to open a chat window occur at the same.
It was working fine before the commit above, because the registering
of a newly open chat window was synchronous.
This is however no longer the case, because it fetches messages
beforehand: it has become a requirement to open a chat window. Since
the registering of a newly open chat window is now asynchronous,
it was fetching messages and opening the chat window twice.
This commit fixes the issue by aborting attempt to open a chat
window if it's currently opening a chat window, as this process may
take some time due to the `message_fetch` RPC.
closesodoo/odoo#30741
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
Purpose of the task is to improve the usability of activity types and
activity scheduling.
Another purpose is alto to protect some master data activity types by flagging
them and preventing their deletion.
Containing
* make the activity type as master data so deletion will be prevented;
* improve the usability of the activity type;
* prevent the deletion of activity type which are used for automated activity;
* change the usability of activity scheduling modal;
This commit is linked to task ID 1907970 and PR #29257.
Before this commit, a user could unintentionally discard a
notification from a document that he does not have access
rights at the moment.
Steps to reproduce:
1. Setup:
- Odoo with multi-company
- Two companies: "MyCompany" and "SuperCompany"
- Two users "Admin" and "Demo", both have access to being in
both companies
- "Demo" has Notification management in Odoo in the user preferences.
- "Admin" is logged in "MyCompany"
- "Demo" is logged in "SuperCompany"
2. Scenario:
- "Admin" mentions "Demo" in a log of a document from "MyCompany"
- "Demo" receives the notification and click on the notification
from messaging menu.
> Dialog prompts that Demo does not have access to the document (OK)
> Empty chat window is open (not OK)
- "Demo" closes the chat window
> Notification is marked as read (not OK)
This commit fixes the issue by aborting the opening of a
chat window if the user does not have the access rights
at the moment. It should prevent marking the notification
as read by mistake by closing the chat window.
Task-ID 1931313
closesodoo/odoo#30414
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.
Christophe Simonis