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>
-Improve no content helper on activity view
-Update chatter after editing an activity un form view
-Avoid context to appear as feedback
When using call_button the context is set as an arg and will be catched by
the kwargs of the called action.
As for action_feedback, we can create a wrapper without kwargs
used when calling this method from a button to avoid this problem.
Another solution would be to change the call_button in order to give
the context as a kwargs. Maybe a possible improvement for master.
-Remove groupby from activity view
group by has no effect on activity
-Change cursor to pointer on record name in activity view
Task: #1878184
PR: #26668
This commit makes small improvements on the messaging menu with
the new module `mail_bot`:
[IMP] When OdooBot has a request, it now adds "+1" to the counter of
the messaging menu. The related preview also has a bold title,
and displays "(1)" next to the title.
[REF] Static previews are no longer in mail_service. This was only
used for "OdooBot has a request" preview. This logic has now
been moved to the module `mail_bot` (was previously in `mail`).
[FIX] Title of response of push notifications permission clearly
states whether permission has been granted or denied
(was displaying "[Object object]" before this commit).
Task-ID 1877502
Definition of '(non-)passive' thread window:
Thread windows can be either 'passive' or 'active'
(default: 'active').
- When opening a thread window in 'active' mode, the messages
are marked as read, and the focus is on the thread window.
- When opening a thread window in 'passive' mode, the messages
are not marked as read and there is no focus on the thread
window. Messages are kept unread until the user interacts with
the thread window (e.g. by clicking on composer).
When the user intentionally opens a thread window, it should
be open in active mode. However, when a thread window is open
without any user iteractions, it should open in passive mode.
The later case is useful in some cases. For instance, when
receiving a new message from a DM conversation, it should
automatically open the corresponding thread window. However,
it should not automatically mark messages as read.
This commit contains 2 bug fixes:
1. When receiving a new message on an active thread window,
it no longer increments the unread counter.
(When the focus is on the composer of the thread window,
the user is immediately reading newly received messages.)
2. When receiving a new message from an unpinned DM conversation,
the newly open thread window is always passive.
(This was not the case before, so when receiving new messages,
it did not increment the unread counter.)
1. Removed `getLocalMessages` method in mailbox, and replaced
with an override on `getMessages`.
(This method was used before the distinction was made
between `getMessages` and `fetchMessages`)
2. Removed unused method `_warnUpdatedUnreadCounter` in
abstract thread window.
(Leftover from an early POC)
3. Set the default value `''` for the status of a thread.
(The method `getStatus` should always return a string)
4. Enforce default value `false` for detached status of channel.
(The method `isDetached` should always return a boolean)
5. Improve readability of some tests.
(removed useless variables and/or redundant code)
This commit fixes some bugs on thread windows, and make some
improvements on tests related to thread windows.
Fixes:
1. Correctly position last visible thread window when there are more
open thread windows than available slots.
2. Closing a thread window now marks it as read.
3. Can now fold/unfold the blank thread window (aka 'New' thread window).
Tests cleaning:
1. Removed unnecessary 'before assertions' in thread window tests.
> Solved with this: https://github.com/odoo/odoo/commit/9b1daa1218f7adf9d741afba607ef5b55b16e3e6
1. Added basic rendering test for a (non-blank) thread window.
2. Cleaned thread window tests
> Split in different files.
> Grouped in 'Thread Window' QUnit module.
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
activity.js was a little dirty with a lot of copy paste.
Most of the common logic is now in a BasicModel.
This commit also add some tests on activity view
Co-authored-by: RomainLibert <rli@odoo.com>
Revision on https://github.com/odoo/odoo/commit/e0a51edd856b36bfdf1cacb4d7e8d70fad7884fa
In the commit above, we added an option to Discuss widget
to render threads specifically for PhantomJS. The reason
for this is that a test was failing, because it needs full
support of CSS flexbox to pass.
However, PhantomJS does not support flexbox very well. As
a result, it was messing with the rendering of threads.
We couldn't make the hack just in the test itself, because
it is already at the moment of rendering the thread that
PhantomJS messes the whole process of the test.
PhantomJS has been replaced with Chrome headless [1], So
the hack is no longer be necessary, as Chrome headless
fully supports CSS flexbox.
[1] https://github.com/odoo/odoo/commit/de84ad9c1f4853cb8a748ee1d0c880081dae9fe2
Before this commit, there was a traceback when attempting to mark
all messages as read from the 'Inbox' of Discuss.
This is due to resetting the 'needaction' counter on threads that
do not not track 'needaction', such as the 'Starred' mailbox.
In fact, only channels do track them and handle a needaction counter,
so this should only be applied on channels.
With this commit, most threads show an indicator when a member is typing
something. e.g.
"Mitchell Stephens is typing..."
Supported threads:
- DM
- (public & private) channels
- Livechat (Website & Backend)
Unsupported threads:
- mailboxes (e.g. 'Inbox')
- document thread (= 'Chatter')
- support channel (with `im_support` module)
Some technical details:
- This is a mix between 'start'/'stop' and 'regular notify' strategies.
- On typing text in composer: notify 'start typing' to all members of
thread.
- On clearing text in composer: notify 'stop typing' to all members of
thread.
- A member can only notify once every 2.5 seconds to the server when he
starts or stops typing something (throttled, buffered notify call).
- On receiving a message from someone that is typing: determine that he is
no longer typing.
- On non-empty and unchanged composer text for 5.0 seconds: automatically
notifies all members of thread that he is no longer typing anything.
(This is like a 'soft / cooperative sender' timeout).
- On non-receiving a typing notification of someone after 60 seconds:
determine that he is not longer typing something (This is like a
'hard / receiver assumption' timeout).
- When some types for more than 50 seconds straight: notify that he is
still typing something (again and again every 50 seconds).
- When two or more people are typing something (Multi-User channels), it
displays at most 2 typing users (ordering rule: longer typers first):
"Mitchell Stephens, Marc Brown and more are typing..."
- Timing summary:
- Usually 2.5 seconds uncertainty.
- Up to 5.0 seconds uncertainty on typer inactivity.
- Up to 60 seconds uncertainty on typer page reload / browser tab
closed / etc.
Future Improvements:
- Detect page reload or browser tab close with loose of longpolling
connection
Task-ID 28188
A document thread is a JS-only entity, which is built from data on
'mail.message' received from the server, or from data of a document.
When we detect a change on the message IDs related to a document thread,
we should update this list on the document thread, so that it knows which
messages haven't be fetched from the server yet.
However, the list of message IDs was not updated on a document thread when
no name could be provided to the document thread, which occurs when there
is no no `display_name` data to determine on the record's name.
In this case, it should update the list of message IDs on this document thread
without altering document name. However, it was neither changing the document
name nor updating the message IDs.
This commit fixes this issue by independently update message IDs and the
document name of a document thread.
Before this commit, this test was failing due to phantomjs assuming that
there could be more messages to display on the screen.
The issues comes from the bad support of flexbox with PhantomJS, and this
test broke when we changed a DIV display with 'flex' instead of 'block'.
For instance, this is the expected values:
thread clientHeight: 960
thread scrollHeight: 1629
message clientHeight: 50
With 30 messages, 50 x 30 = 1500 < 1629 and 960 < 1629, so there are
enough messages loaded with this screen and we are not at the top of
the thread (this is the case when clientHeight = scrollHeight).
However, with phantomJS we have the following values:
thread clientHeight: 944
thread scrollHeight: 944
message clientHeight: 259
As a result, with 30 messages, 50 x 30 = 1500 > 944 (looks like
messages do not vertically collide ?) and 944 = 944 so it assumes
we are at the top of the thread, so it fetches for more messages.
This commit fixes this test by enforcing a special rendering of the
thread for phantomJS.
Unfortunately, we can't simply make the hack on the test only. We
have to make discuss and thread aware of this because they should
adapt their rendering right away
- no more bootstrap `o-flex` mixin
- no `$gray-light` (replaced with `gray('600')`)
- replace event `click` with `show.bs.dropdown` for dropdown
- use `!important` on previous `hidden-xs` (because `d-*` use `!important`)
Before this commit, when we received a new message, the counter was correctly
updated, but not the last message in the messaging menu preview.
This is due to making changes to the counter before adding the message in the
thread. When there is a change in the unread counter of a thread, it warns its
views. The messaging menu renders the previews of each threads in the preview
items, using in particular the last message in the thread.
This commit fixes the issue by making changes on the unread counter of a thread
after the message has been added to the thread.
Christophe Simonis