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
Before this commit, when hovering on a email icon of a message
in chatter without any customer email data, there was a crash
with the following error message:
"No enumerator given to foreach"
This was caused by `undefined` being passed to `t-foreach` when
there are no customer email data on the message. Since
`undefined == null`, it raised the error above.
closesodoo/odoo#31587
Signed-off-by: =?utf-8?b?QWxleGFuZHJlIEvDvGhuIChha3Up?= <aku@odoo.com>
In some special instance, a mention could get linked and the user would
not really be linked.
This is because of a difference between linking the mention and adding
the user as follower that required a space after the mention.
With this change:
- `[adding mention]@admin [backspace].`: was linked but not added as
follower => now it is not linked either.
- `[adding mention]@admin [backspace][enter][adding mention]@admin `:
the first @admin was linked => now the second is linked
Without the change, added test fails with:
"should not contain a link in the message content"
"should not have linked mention without space"
opw-1934946
closes#31433
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
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
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.
A new field on activity type allow to change the behaviour of mark done & schedule next:
-marking as done will automatically schedule the next activity, based on the default_next_activity.
-It should also be impossible to edit an activity when this flag is on.
task: #1884521
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
It was blue over blue with the change of the navbar.
Before the navbar change, it was blue over black.
To avoid blue over blue, counter is now green, so that
it is green over blue.
Christophe Simonis