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.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
By default, users are supposed to be able to write messages
in threads only if they have the write access on the record.
This behavior is the behavior defined in Odoo 8.0.
This behavior can be changed by defining
`_mail_post_access` on the model,
to allow the creation of new messages
if the user has only the read access, for instance.
This is the case on `project.issue`, for instance.
Since 9.0, @ revision 88b8cd0587,
this behavior was broken: Any users having the read
access on the record was allowed to write messages in the thread,
while this should not be the case, except if
`_mail_post_access = 'read'`
has been defined on the model.
This is because the SQL query which is performed in order
to know the thread messages the user has been notified of
was expected to return only the ids of the notified message,
while it actually always returned all the message ids of the thread,
because of the LEFT JOINS, e.g.
```
LEFT JOIN "mail_message_res_partner_rel" partner_rel
ON partner_rel.mail_message_id = m.id AND partner_rel.res_partner_id = (%%s)
```
Instead of just checking the ids of the messages returned by this
query, it must check that one of the two columns
`partner_rel.res_partner_id` or `channel_partner.partner_id`
is filled, meaning the partner has been notified of the message or
is a member of the channel the message has been posted to.
opw-668589
As it's done few lines below,
in `set_message_done`.
The user could have a notication associated
to a message he has not, or no longer, the
write access, but he should still be able
to mark it as read.
opw-671188
When a specific SMTP server is set on a mail template, it is never used
when the mail is sent. There are two reasons:
- `mail_server_id` is a read-only field set by an onchange. However, a
read-only field is not sent to the server, so the information is lost.
- The information is stored in the context of the object `Mail`, but it
is never used. Moreover, when the method `message_post` is called, the
`Mail` object is not used to post the message, so the information is
lost again.
The fix includes two parts:
- the `mail_server_id` field is not read-only anymore. Actually, there
is no reason to make it read-only.
- the information is stored directly in the mail values and used at the
appropriate moment.
Fixes#6554 (from v9.0)
opw-669958
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.
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.
Except for messages, activities on a document like internal notes posted
trigger notifications to partners and channels following the corresponding
activity's subtype.
Rev. 69ed801 rightly re-introduces a filter on followers to prevent notifying
more partners than necessary. Unfortunately, this filter doesn't take into
account channels, which are thus automatically removed from followers to
notify, whatever the subtypes they follow, e.g. internal notes on a document
don't appear in channels following the 'Note' subtype of this document.
This commit makes sure that channels always pass through that filter, but warns
users that public channels should probably not following internal subtypes.
Also makes the edit subtypes dialog html valid (li's must be inside, e.g., ul).
Indeed portal and public users may have to read internal subtypes to perform some
check in the code. However the rules do not allow them to read those internal
subtypes. We have to read some subtypes as sudo then.
The read more / read less in chatter has been removed in the new timeline and
then cleaned timeline introduced at cc6d2aa995.
This feature has been brought back at revision 486aab5098.
However a new cleaning removed the feature at revision 2a5f07e0b9.
This commit brings back this feature for the second time. Next one brings free
cookies.
When having a tracking, the subtype description should be displayed. This is
used for tracking linked to a subtype like Task Opened, Task Blocked, ...
This feature was forgotten when refactoring the chatter for v9 and is now
back.
The 'string' attribute for both needaction_partner_ids and needaction fields
was 'Need Action'. This was problematic for example in the custom filters of the
searchview as it looked like the same field was appearing twice.
Update mail.pot as well.
When calling 'set_message_done' on a message which is a needaction for several
partners, the method was executed as root. This was an issue for the triggered
notification, as it was thus always sent to the admin.
For example, when Demo user marked such a message as read, he never received
the notification, but the Admin did, and its notification counter weirdly
decreased, while the one of Demo user remained the same.
Mainly concern the client action:
- Display needactions per channels
- For all channels except Inbox, clear needactions when opening the channel
- Add snackbar to undo needactions clearing
- Display a separator between read and unread messages in threads
- Fix active channel (for Inbox and Starred) display in sidebar
Various minor changes in chat_manager:
- Code refactoring of bus notification handler
- get_channel() don't fallback anymore on first channel
- display star/mark as read icon next to the message title instead on
the far right
- display unstar all message in channel starred
- enable/disable the 'unstar all' and 'mark read' buttons depending on
the number of messages in the corresponding channels
- display star on the left sidebar in 'squashed messages'
- tweaks to padding in client action
- display hash in channel name in lighter tone
- light opacity in sidebar
- star icon in message sidebar is clickable + small less refactoring
- message sidebar is aligned with the message now
- messages are not squashed in inbox/starred
If a user does not have write permissions on a model, he should still be
able to remove himself from the many2many relation.
This caused a problem: some messages could not be modified by a user
(star/unstar or mark as read)
By default the author of a message is always removed from the notified recipients.
However in some cases it is interesting to be able to notify the author. A context
key has been added that handle that case.
Read more / less feature is back (and probably ugly). It has probably been
removed when refactoring the old chatter.
[FIX] tools: html shortening: encoding issue
mail_channel: call create with mail_create_nosubscribe=True to not subrscribe creator as follower,
since channel is not a mail thread (channel followers make no sense)
mail : adaptation with new chm controller for attachment, and remove author_ avatar from message format
This commit add instant messaging features in mail module to make it a real team collaboration tool. Lots of these new features will replace Timeleine view (which is not removed in this commit). Many files have been moved, split or created for a better structure.
- My Channels : A user can be member of channel (mail.channel). These are discussion group, but also an aggregate of notification. Setting a channel as document follower, it will receive all the message (of the chatter) in real time, as information stream.
- A new Inbox : this aims to replace the timeline view. The user will see its channels grouped by 'slot', and receive the message in real time. Jump to the form view, invite people, create private discussion group, talk directly to another employee, ... are the main features. Your message can still be starred. The 'Inbox' will only contain your needaction.
- Needaction concept : a needaction is a message calling you to do something. If you follow a document as a person, the posted message will be 'needaction' for you. It can also be a message where you are mention with a '@my_name' (this feature is not added in this commit).
- The chatter doesn't change so much. It still allow you to see the discussion about the document, to star some message, and treat your needaction.
- Chat : the only way to have a minified conversation is from the Inbox Client Action. It allow you to keep an eye on a channel when working on document.
- Compose Message : it is now common to the Inbox, and the chatter. It offers shortcode substitution, attachments management, and optional subtype.
- UI : the chat window has been clean, they have a new look now.
To do so,
- Chatter code have been completely rewrite, independently of timeline view
- Add 'bus' as mail dependency, to insure real time
- A mail.message is broadcasted on the bus channel (db, mail.channel, channel_id), and a channel header on (db, res.partner, partner_id)
- Extracting mail_thread mixin used for Chatter and ChatMailThread (Inbox client action). This uniformize the programming structure with the server side
- Clean CSS style and use LESS instead of CSS
- Define a new messafe format (message_format method in mail_message.py), compatible with fetching and broadcasting
- Apply guideline coding conventions
This commit also break the module im_livechat, since im_chat models don't exists anymore and will be fixed in the next commit.
Thanks to Thibault Delavallee (tde) for the long debates and precious advices, Richard Mathot (rim) for the support, Simon Lejeune (sle) for the client action layout, and the Usability Team (apr, lle, bst yti) for the long testing.
Conflicts:
addons/mail/models/mail_thread.py
- mail_message: fixed internal subtypes
Indeed has_group works only for uid and does not care for any given recordset.
Probably we need a is_in_group method on res.users. Someone smart could code it.
- mail_message: update message before notify
This way in the various notify methods, the message is correclty updated with
needaction and recipients. Also cleaned some comments.
- mail_message: avoid email loops
Do not notify people having the same email as the message / email to propagate.
- mail_message: fix access right issues
When computing recipients and partners to email, use a sudo for some internal
computation to avoid access rights issues. Indeed public user may go through
this method (forum for example).
Replace deprecate controllers like /web/binary/image, /web/binary/saveas...
Use ETag for all content with 'unique' option to cache the content if the content is never changed.
Jeremy Kersten