session.context no longer exists, it is session.user_context
Add the missing context in the message_fetch call. The dates in the chatter were
not formatted according the user locale.
The tacked messages in the chatter were parially translated.
e.g. "Lead created"
The call did not gave the user context and the subtype message was not
translated.
Closes#14589
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
When clicking on "Show older messages" in the bottom of the chatter, the
page would jump to the top when the additional messages are loaded.
There is already a functionality in a discuss channel to stay at the
previous scrolling position (related to the content) :
https://github.com/odoo/odoo/blob/ffe0db0d/addons/mail/static/src/js/client_action.js#L506-L521
This fix does the same steps for the chatter.
opw-692010
Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.
opw-687781
When a user sends a link thanks to the livechat, the link is not
clickable is the recipient is on the frontend (e.g. visitor of the
website). On the other hand, a link sent from the frontend to the
backend works.
This is because the message is sent as "html" from the backend,
therefore no link conversion is done during the post-process of the
massege (method `message_post`).
Note that a link sent and received in the backend works because
additional formatting is done (convert emojis, add links...).
opw-686063
Before this commit, if a message thread was loaded 2 times, the first time
the date was well formatted, the second time that fail because momentjs cannot
parse the localized date from some locale.
Luckily, it was not bugged by default in english, because moment was able to
reparse a localized US date. But in some local as french, momentjs cannot parse
the localized date and return 'Invalid date'
Now, we move the code, to be processed only once by the chat manager, and not
in each process of the thread.
This commit closes issue #13258
Courtesy of @aab-odoo
It might happen that a transaction produces more than one message in the
chatter. In this case, the messages are created with the exact same
date, and they might appear in the wrong order in the chatter.
We therefore sort the messages by id, and not by date. Note that the
messages are already sorted when received from the server, but the web
client has its own management of the messages' order. Relying on the
server order might imply to change other parts of the code on client
side, which is something we want to avoid on a stable version.
opw-681049
When the mail composer is opened thanks to the "Send Mail" button in
Discuss, it's possible to save a mail template, but the user can't
access it anymore later on.
This is because the field `model` is by default empty in this specific
case since this is a client action. However, when saving the template,
the default value 'mail.template' is used for the `model` field.
Therefore the domain on the `template_id` field prevents the user to
find back the model he just saved.
The fix sends the `active_model` in the context with the value
'mail.message', so that the `default_get` method of
`mail.compose.message` will set the appropriate default value.
opw-677936
When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.
Related to #12327
Courtesy of @aab-odoo for help and review.
If the "NEW MESSAGE" or "Log an internal note" are clicked succeedingly
too fast, we can get into a situation where the composer is init'ed but
have not already been start'ed.
closes#11952
opw-675973
In Discuss, if a message was selected as message to reply to, it wasn't reset
when switching to another channel. So if the user sent a message in that other
channel, the message was sent as reply to the previously selected message.
This rev. ensures to always unselect messages when switching between channels.
Closes#11879
Before showing a chat notification, a check is performed to ensure that the browser does support
notifications. On browsers that do not support Notification (IE, android native,...), the check was wrong and
would eventually cause a traceback. This will no longer happen.
When an user sends an email from the chatter then quickly switch to
another record, it may happen that this.composer is already destroyed.
We prevent to display a traceback with this fix.
The name of the static channels ('Inbox', 'Starred') are not translated
in the breadcrumb. The reason is that at intialization of the chat
manager, the translation are not yet loaded.
The fix is to use the lazy translate functionality, which applies the
translation when the string is displayed.
Courtesy of @aab-odoo
opw-673856
For a message to be considered as a private message,
the message must have:
- `no_auto_thread` set to `False`
in other words, it must not be attached to a thread
- no `model` or `res_id` must be set on the message
meaning the message is not attached to a specific
record thread.
See `_get_message_id` in `mail/models/mail_message.py`.
Before this revision, the mails sent from
`Discuss` > `Send mail` were not regarded
as private messages,
but as a kind of mass mailing messages,
with a `reply-to` wrongly set.
Any attempt to reply to these mails
failed with a delivery failure notification.
This was because the `message-id` of these messages
contained `reply-to`, and such message-ids are
treated as a special case in the messages routing
(basically, the match on the mail references is disabled
for these messages containing `reply-to` in
their message-id).
opw-669241
The button 'mark all as read' used to mark all messages as read, which
is not usually what the user wants when there is an active filter in the
search view. This commit make sure that the domain is send to the
server and used correctly.
The problem was that mentions weren't correctly erased with DELETE key (in some
conditions), or when replacing mention text. When this happened, the mention
didn't appear in the message, but the message was even tough sent to the erased
mentioned people.
With this rev., we don't try to detect erasing on the fly anymore, but we
rather validate mentions before sending the message with the content of the
input.
opw 669362
When the user can't read the model res.partner, former code tried to determine
whether or not the user was follower of the document. This was wrong for three
reasons.
First, it performed an RPC to get the partner_id of the current user, but this
info is already stored in the session so the RPC was useless.
Second, the partner_id isn't helpful to know if the user is a follower because
everything we have is the follower_ids, which aren't ids of the res_partner
model, but ids of the mail_follower model (compare apples and oranges...).
Third, we anyway didn't use that information at all as the button indicating
whether or not the user is a follower wasn't displayed.
This rev. simply removes that useless RPC and only displays the count of
followers as previously.
- swap reply-to and mark-as-unread buttons in threads
- remove blockquote from stripped html in channel previews
- readd padding to no-content message in threads, also to no match found
message
- add 1 to chat window z-index to prevent control panel buttons to show
through it
On printing, the announcement bar URL was displayed
in the printing result.
e.g.
`https://services.openerp.com/openerp-enterprise/ab/register/...`
was displayed at the top of the print.
This is related to the revision 50a4ca31f8.
This is due to this simple typo, the according CSS rule was
never applied because of it.
This bar was never displayed as the remote css was always empty.
When using the enterprise web client, the printing stylesheet show the
target of links (<a> tags) between parentheses, including the one from
the annoucement bar that should be kept hidden.
When a new message arrives in a DM or a livechat, the channel is automatically
open in a chat window if we aren't currently in Discuss.
Don't apply this behavior in mobile and we probably don't want to see a full
screen chat window everytime someone sends us a message.
Thus also remove the 'Detach' button in Discuss's control panel as we can now
directly detach channels with the messaging menu.
Also removed unused handler on 'messages_read' since rev. 30c26d7.
When a new message arrived in a non pinned DM, the unread counter was
incremented twice ; once because the channel info (along with its unread
counter) was fetched from the server as the channel wasn't in the JS cache yet,
and once when adding the message in the JS.
With this rev., we only increment the unread counter when a new message arrives
if its channel is already in the JS cache.
Problem occured when the first call to get_channel_preview was directly
followed by others, before the channels_preview_def was resolved. In that case,
the other calls all returned an empty array, as only the channels_preview
array was only filled with the RPC result for the first call to
get_channel_preview (the one which initiated the RPC).
Those items might have been rendered and inserted into the DOM before the chat
manager initialization was completed. As those items rely on chat manager's
data, they should wait for it before executing their action (inbox redirection
and channels preview display).
- discuss notifications are always sent natively if possible
- clicking on native notifications focus the tab
- clicking on native notifications closes them
- granting notification permissions will display a confirmation
notification
A missing feature in discuss was the possibility to directly reply to a
message from a channel without opening the document. This commit add
that feature. Now, there is a small 'reply' icon in channels (including
inbox/starred) if the message comes from another document. This icon
opens an extended composer, which will post the message in the document
chatter.
Commit c04103f re-renders the thread every minute to update messages' date.
As a consequence, the expanded messages are lost (they are shortened again).
This rev. makes sure to keep those messages expanded.
Martin Trigaux