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
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
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
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
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
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
Before this commit, the buttons 'New Message' and 'New Channel'
were shown in all tabs of discuss mobile, even though they should
only be displayed in some tabs.
This issue comes from a change from BS3 to BS4, in which the classname
`visible-xs` has been replaced with `d-block d-md-none`. With BS4,
the classnames `d_*` are now `!important`. As a result,
`d-block d-md-none o_hidden` still displayed the button because
`o_hidden` does not have `!important`.
This commit fixes this issue by removing the reliance on `o_hidden`,
and now only uses `d-*` for the visibility of the button. The toggling
of `o_hidden` has been replaced with adding or removing the classes
`d-none` (hidden) and `d-block` (visible). Those buttons are not shown
in desktop thanks to `d-md-none`.
Task-ID 1877502
Before this commit, it was not possible to mark a document
thread preview as read from the messaging menu.
This issue comes from the fact that document message previews
are built from messages in the Inbox. The computation of
the unread counter is correct for the preview, but not for
the associated document thread object which has a counter of 0.
Since it is only possible to mark as read when the counter is
strictly greater than 0, the 'mark as read' did not have any
impact.
This commit fixes this issue by ensuring that the unread counter
of a document thread matches the number of needaction messages it
contains.
Task-ID 1875668
The combined domain for moderated messages used to trigger a complex
database query with two OR conditions on the mail_message table.
Unfortunately PostgreSQL seems to be unable to optimize this with
indexes, or to detect that one of the conditions is void (included `AND
FALSE`). On large mail_message tables, this significantly slows down
calls to message_fetch, e.g. 6s instead of ~70ms, while returning the
same results.
As a workaround, move the logic for generating the moderation domain to
the server side, where it can be:
- optimized out when the user is not a moderator
- split into 2 distinct DB queries in order to avoid the pathological
case
After this change, calls to message_fetch with and without messages
to moderate execute in respectively ~50ms and ~150ms, instead of 6s, in
a test database with 25 million messages.
The modified message_fetch signature is backwards-compatible.
+ modified mock server used for the tests, which unfortunately
duplicates most of the business logic.
Since saas-11.4 the subtype dropdown don't keep changes of subtype.
Before saas-11.4 the update was relying on the fact that the follower id
changes on each subtype edition. This is no longer the case.
The test is addapted to remove the hack simulating this behaviour.
The read_followers route is not called if no there is no changes
in the follower ids
https://github.com/odoo/odoo/blob/905e01921f3c3ef43ace6fc537d1d8c0d280002c/addons/mail/static/src/js/followers.js#L195
Leading to the follower list not being update
Note that the subtype update in dropdown was working fine after adding a
new follower: the read_followers will return a None as suptype when called
for a list of partner not containing the current user. Since the subtypes
was falsy, the render was not rendering the dropdown again, keeping
the value of the checkboxes. We can still create some inconsistency by
editing the subtype from the follower list. To avoid that a check is made
when updating subtypes after calling read_followers.
The chosen solution here is to keep the update on subtypes in memory.
This will avoid a call on read_followers to fetch information that we
already know, using the assumption that the operation was successfull
whish should be the case when a user edit subtypes on a record
he has access to.
Others solutions:
-force the call to read_followers with the current user, maybe by removing
it from this.follower after editing subtypes.
-call read_subscription_data explicitely
Obviously follower.js should be refactored to fix this a better way.
Task: #1886982
PR: #27093
Refactor ‘mark as done’ popup JS in order to use a sliding panel layout instead.
Sliding panels are currently needed in kanban views, where activities are listed in a dropdown that can't handle popups because of CSS overflow and lack of space.
Since this new system check for default bootstrap data-toggle attributes, it could be easily used elsewhere changing the buttons's data-toggle and providing the necessary container for the “mark as done” form.
Reason: The Attachment count of mail_thread is used by the new
attachment button of the chatter, the compute field has been chosen
over a search_count JS RPC to keep a synchronous chatter and prevent
flickering.
This commit refactors those changes to follow the naming
conventions of mail_thread and to optimize the count method for
eventual reuse follwing TDE's advices.
- Changed the name of a mail_thread's related_attachment_count into
message_attachment_count.
- Changed the count method to a read_group.
PR: 26989
Task: 1860031
This commit fixes the handling of the service parameter
in a mocked environment:
- updated docstring: now an object (previously an array)
- no longer used by mocked server (unused parameter)
- enforces default value for this parameter (empty object)
- added two new actions to the form view debug action list,
both opens list (+ form) views of messages and attachments respectively
for which the domain is restricted to the current record.
task: 1860031
- Added a new button to the chatter that displays the amount of
attachments on the current record and when clicked, all the attachments
attached to the current record
- added mail.FormView (includes), used by the chatter attachment
button to fetch the field value of attachment_count.
- added a computed field "attachment_count" to mail.thread that
contains the amount of attachment attached to the record.
- changed the followers div, it is now sharing a "right side"
area with the attachment button.
task: 1860031
Revision on https://github.com/odoo/odoo/commit/ec8c505bc1c9ec21939e9ffef53a9cc6f63f30c7
The commit above changes the way threads are rendered: the template
now uses a thread object, instead of a list of messages.
However, it was not handling messages that have been filtered from
the searchview. As a result, it was not possible to filter messages
at all.
This commit re-adds the possibility to filter messages, by providing
information on the domain of the thread in the template.
Task-ID 1877502
Before this commit, the search option buttons were not
hidden when clicking on the zoom-in/zoom-out button next
to the searchview.
This is due to updating the control panel with the list
of buttons as the searchview buttons, instead of the
container. Since the visibility of the searchview buttons
is defined on the container, the toggler button and the
search view options lost synchronization.
This commit fixes the issue by providing the container
that is shared between search option buttons.
Task-ID 1877502
On an activity, click Mark as done, the popover pops over
Now write some text in it, but click somewhere else, like to copy/paste something
The popover looses focus, and your text disappears
After this commit, we store the value of the popover when hiding it,
then, when when showing back the popover, the value is reinjected
OPW 1873999
closes#26315
-removed force_ext from ir.http.
-added signature arg to web/image to differentiate cache entries by URL.
-added an embed youtube viewer for youtube URL's
-added a PDF splitter to the PDF viewer UI
-added tests for mail's Document Viewer
-added a "signature" param to web/image to go around the browser cache
-thumbnail field of ir.attachment is now stored in the filestore
as a distinct attachment.
task 1853490
Co-authored-by: Pierre Paridans <app@odoo.com>
Alexandre Kühn