When there are no available action buttons on the email (as Follow, View Task,
Convert to Opportunity), i.e. when the user/partner is not an employee, and
when the message subtype is 'Discussion', send a plaintext mail instead of
a formatted one.
Use case: Strange to receive a mail like this when you're on a lead and you
receive formatted mails.
Finally add support of CIDs in incoming emails. Inline images are recognized
and added as attachments. Image links are updated from src=cid: to src=link
using the /web/image controller.
It has been decided to keep the image in atttachments instead of putting them
in base64, like proposed in various PRs. Indeed we prefer to store this data
into the attachments instead of directly putting it in the mail_message table.
Moreover this enable the display of attachments in the chatter and record views.
the messages in a thread were previously rerendered every minutes to
update their timestamps. This commit only update the timestamps, not
all the message. This will allow us to keep expanded/folded state in
messages without collapsing them every minutes.
[IMP] mail: add read more/read less support client side
Messages are cleaned up and tagged server sides, with a attribute
data-o-mail-quote. This commit replace their content with a clickable
read more link, which toggle its display.
Quote detection is now done in the sanitizer itself. It tags nodes that are
inside quotes (signature, text quotes, email quotes). The purpose is to remove
html_email_clean and have all the html cleaning / sanitizing inside a single
function. When a node is tagged, data-o-mail-quote is set on the node.
This attribute is added in the whitelist of valid attributes for the
sanitizer.
[REM] Support of shortening messages. The read more / read less will only
display or hide detected quotes and signatures. Shortening messages above
a given amount of characters is not supported anymore. Indeed it adds much
complexity to the sanitizer without adding much value to the result. The
primary purpose of the sanitizer is indeed to remove noise and unnecessary
content.
[TESTS] a lot of test are not necessary anymore, as read more / read less
display will be moved in the front-end and as the shortening has been
removed.Tests have therefore been cleaned and simplified.
[DEMO] mail: small demo update to include a bit quote detection
Do not strip class by default on html fields, this was an error. Currently
only mail_message body field should not contain classes. Indeed as external
content can be stored through the mail gateway we do not want to keep the
classes.
Before this rev., editing the subtypes of other followers was only possible if
the current user already opened a record of the same model of which he is
himself follower.
- extended_chat_window feature in its own files: as it is only available in the
backend, we don't want it in the frontend assets (which contain the 'basic'
chat_window)
- move followers feature in its own files
- creation of the 'mail.utils' module in utils.js
- creation of systray.less to define the style of the mail item and dropdown
in the navbar
- use of chat_manager's search_partner function in PartnerInviteDialog
- some code linting
When loading a form_view with the follower widgets, an RPC was performed to get
the followers info (name, email...), and if the user is one of the followers,
a second RPC was done to retrieve the subtypes.
This rev. batches those two RPCs. Also simplifies read_subscription_data() as
it is now always called with a follower_id.
A few code refactoring as well.
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
`write` expects a `dict` for the `values` argument,
`part[record.id]` is a list of commands to add new
followers.
See the returned variable `specific` of the method
`_add_follower_command` in `mail_followers.py`.
Surrounding `part[record.id]` with a `dict` with
`message_follower_ids` has probably been
forgotten by oversight.
`gen` and `part[record.id]` have actualy the same
syntax, and the `write` done with these variables
should therefore be called the same way.
opw-669376
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.
Remove the RPC to retrieve the action_id of the client action as do_action()
can take directly the xml_id, and batch the RPC to retrieve the menu_id with
the initial RPC used to fetch channel slots, emojis...
- 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.
Before, every user was set into this group. It means that a portal
user received elements in his mail context, like the buttons to
open a document or to follow it. Now, only the employees will
receive this kind of information
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.
Two problems occured:
- when the user hadn't seen any messages of a channel, the seen_message_id
was null and doing seen_message_id < msg.id to retrieve all messages
received after the last one seen didn't return any message (null < x is
always false)
- messages sent by visitor on the livechat doesn't have any author_id, so,
again, doing msg.author_id != partner_id is always false, and as a
consequence, server-side, the messages sent by visitors were always
considered as read
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
Géry Debongnie