Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.
This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.
Task-ID 2026101
closesodoo/odoo#34291
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Create an invoice, validate it, print the invoice from the print menu,
as of the paperclip value in the chatter, an attachment has been added.
But if you click on the paperclip, there are no attachments. You need to
reload the page in order to access the attachments.
The problem is the internal flag indicating that all attachments are
fetched is wrong. This fix resets the flag when the paper clip value
changes.
opw-2008344
closesodoo/odoo#34171
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, it was not possible to have the field message_attachment_count
explicitly defined in the form view. It crashed inelegantly if it were the case
After this commit, it is possible to have that field in the form view
OPW 1998503
closesodoo/odoo#34143
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.
The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.
opw-2006647
closesodoo/odoo#34076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes a js crash that occured when the user was trying to
edit a new record while the chatter was not completely loaded
(this.field.thread.$el was not in the dom yet)
Behavior before this fix:
Traceback js & impossible to edit the form afterward.
Behavior after this fix:
no traceback, still possible to edit the form normally.
The thread will display on next chatter re-render. Could be forced by
triggering an onchange.
opw-1986061
closesodoo/odoo#33381
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
As the message was set globally in the file, a _lt was needed for a lazy
translation
Fixesodoo/odoo#26288closesodoo/odoo#31761
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When posting a URL containing a semicolon, odoo stops the link
before the semicolon instead of continuing the link to the end
although it is a valid characters in URL (see RFC-3986)
e.g. the url "example.com&foo;bar" matches "example.com&foo"
instead of the whole link
opw-1918367
closesodoo/odoo#30198
Start a message mail (respectively note) in the chatter. Attach a file.
Switch to note (respectively mail). The attachment is lost.
With this commit, we keep the attachments after the switch.
opw 1925588
closesodoo/odoo#30197
Open a record having a chatter, edit a field, add an attachment, leave
the page. The discard warning popup in not shown.
When an attachment is added, it reloads the record to fetch the new
`attachment_message_count`. Reloading the view was discarding the
changes because the `keepChanges` option was not set and defaults to
`false`. The changes were discarded thus the internal `_isDirty` flag
evaluated to `false` thus the popup was not shown as nothing would have
been saved.
The option was set in another `attachment_message_count` reload already,
in `chatter.js@_openComposer`.
opw-1974147
closesodoo/odoo#33180
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The follower button had a useless fixed width which made it overlap with
other buttons.
Fixesodoo/odoo#29387Closesodoo/odoo#33063
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
When post_refresh is set to 'always', the displayed record is entirely reloaded
each time a message is posted in the chatter.
However no such thing exists for when attachments are uploaded.
This is of use e.g. when in the view there are fields that have attributes that
depend on computed fields, themselves dependent on the record's attachments.
One such case is the OCR.
opw 1950403
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.
11.0 backport of 12.0 #28474
issue found when checking opw-1904029
closes#28506
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
This fix prevents the chatter and attachment box
from assuming that there is a mail_thread on the record;
Reason: if a chatter is set on a record that doesn't inherit
mail_thread, the attachment box will generate errors.
closesodoo/odoo#31206
This commit fixes two untranslated terms in the activity view.
From the cohort view, when clicking on a cell to see details, the title was not
translated (missing _t call).
The content was not translated either as the language was not present in the
context.
36d45175b0 was a first step to fix it but while self.record contained data,
self.record.getContext() returns an empty dictionnary (no context is set in the
cohort view).
When computing the context, check that it is not empty, otherwise, fallback on
the session context.
opw-1936855
closesodoo/odoo#30942
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
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 a user had some meetings planned today
and open the systray activity menu, the counter would disappear.
This was caused by a weak computation of the counter that relies
on activity having always a total counter. This was not the case
for activity that are today's meetings: Counter would be computed
as `NaN`, and since `NaN` is falsy, it won't display the counter.
Today's meetings have no reason to have a counter, so this commit
fixes the issue by letting those activities not change the
computation of the counter.
closesodoo/odoo#30695
Steps to reproduce:
- Edit a record.
- Log a note or send a message with an attachment.
- Save the record.
Bug: changes made to the record are discarded.
Because uploading an attachment triggers a reload without 'keepChanges',
the record values are read from database.
However displayed values are not updated, so there is no feedback that changes
have been discarded.
On save, the page is reloaded so the user sees that changes have been lost.
Introduced by 7f97c9fc05.
opw 1923824
closesodoo/odoo#30642
Steps to reproduce the bug:
1. open an app such that there is a breadcrumb (e.g. an employee form view)
2. create a chat window with a user
3. click on the expand button to open the chat in Discuss
4. unsubscribe from the thread
5. click on the breadcrumb to go back
=> Traceback
When expanding the chat window to open Discuss, it registers a callback which
triggers an event on the mail bus. This callback is called when clicking
on the breadcrumb.
Because the channel was left, any related chat window is destroyed.
Since the widget is destroyed, it has no parent, so any service call
returns `undefined`, hence `getMailBus` returns `undefined`.
Fix: check if mailbus exists before triggering.
closesodoo/odoo#30640
Sending a message on the chatter is painful as you need to scroll to see
the buttons and click to open the composer. Then again click to set the
focus in the composer (making the keyboard appear) and scroll again to be
able to write your message.
On a view form when clicking on the "New Message" or "Log Note" buttons the focus
should be put in the text field, then opening the mobile device keyboard
and scroll the view to make the text field visible.
NB: in some case on Android (both WebView and Google Chrome) the scrolling is
not operated correctly resulting into the text field being hidden behind
the keyboard. This issue looks related to some timing between the actual
focus() call and the keyboardi appearance triggered by the operating system.
Sadly we don't have any control on that part.
Related to task 1891955
closesodoo/odoo#29239
When creating the list of attachments, no fields information was given, making
the search_read read the content of each field, including the infamous datas
Already fixed at 73d9b9588f but the domain was not backported
Fixesodoo/odoo#30394closesodoo/odoo#30415
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 follower's list has an ancestor (the o_chatter_topbar) that has a 33px size.
Thus it has not been given any max-height, so that it can overflow
that 33px limit.
But it also means that it can overflow the screen, without any scrollbar,
so long lists are unreadable and unusable.
We set the max-height to a reasonable value, allowing for scrollbars.
opw 1922062
closesodoo/odoo#30211
Before this commit, the process of positioning chat windows
could fail if one of the tabs had discuss open.
When a chat window was hidden and become visible, the algorithm
was not updating the state of the chat window to "visible" when
discuss was open. As a result, it was always trying to make it
visible, resulting in an infinite loop and raising the following
error message:
`Uncaught RangeError: Maximum call stack size exceeded`
This commit ensures it works even when discuss is open.
opw-1919327
closesodoo/odoo#30137
opw-1921686
The failed mail notification group all the records of the same
model that failed to send an email.
Before this commit, the failed mail notification displayed as
title the name of the last record that failed to send an email.
Now, the notification displays as title the model name.
closesodoo/odoo#30134
Alexandre Kühn