When creating a new record, read_followers() was called without res_id and it
produced an error as the argument didn't have a default value. That argument
wasn't used anyway so this rev. simply removes it.
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.
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...
Methods get_formview_action can be called by sudo() so for knowing the
real user they should prefer context['uid'] to uid.
Without the action `/web` can't figure out that e.g the view we want is
the one for portal user and not the default one.
With this fix, portal user (not in base.group_user) get to the intended
view with the intended menu when clicking on a invoice/sale order portal
mail link. As for other user there is no change.
closes#10681
opw-666260
Two RPCs were performed by the chat_manager on webclient launch. One of them
was about emojis, and recent messages received in the past 10 minutes in
detached channels. This RPC has been removed as the emojis fetching can be
done in the other RPC (mail/client_action), and the recent messages are not
useful since the refactoring of mail and the introduction of the chat_manager.
The route `/mail/unfollow` is used by the button
`Unfollow` in the mail notification template so a user
can remove himself from the followers of a thread.
To be able to remove yourself from the followers,
you need to have the write access on the thread
(see `message_unsubscribe` in `mail/mail_tread.py`)
which you perhaps do not have, for instance if you
are a portal user.
The unsubscribe of this follower from the thread
should therefore be done as sudo.
opw-659295
The purpose of this commit is to improve the overall performance of the mention
mechanism of the client action and chatter composer, by pre-fetching some data.
First, the employees are fetched at chat initialization (basically, at web
client initialization), if hr is installed.
Second, when focusing on the composer of a channel, the members of this channel
are fetched. In the case of a chatter, the members are already known as they
are the followers of the document.
When the user types a mention, we first display suggestions from the pre-fetched
partners, and we only perform an RPC when there are no more result matching the
search string. This RPC searches among user, and then partners if there aren't
enough matches.
A few side changes occurred:
- auto_join set to True on user_ids field of res.partner to boost the query
that searches partners that are users
- the '/mail/read_followers' route now returns follower's email as well, as
we need it for the mention;
- a partner can now be mentionned several times in the same message;
- mentionned partner previsualization has been removed, mainly because of
the previous point, but also because it simplifies the code;
As this method is overided in several modules, the mix of new and
old API makes it difficult to handle. Indeed in some cases we
receive the expected dictionary, sometimes in a list, sometimes
in a list of list, due to api.one decorator.
This is a change in the method API, however it is currently completely
buggy. Moreover this method is used internally and should not be
used as an external API. Lastly, this method is new from v9.
This controller is mainly used by im_livechat which don't send html message. It is more secure to force it in plain text. If anonoymous user write html tags, it will be escaped and sanitize.
Use the (dbname, 'ir.needaction', partner_id) channel to broadcast needaction to partner. Some message can be needaction, without belonging to a mail channel of the partner. Keep the (dbname, 'res.partner', partner_id) channel for conversation header.
Previous commit (3304b31938) was not performant enough for AL, so got special autorization to make a particular controller for mail.message author avatar. Avatar of message is avaiblable if current user has 'read' access right to the document. Otherwise the default avatar is one white pixel.
On follower list of a document, the user can (if access rights granted) edit the subtype subscription of other follower. This open a modal with checkboxes. This is commit make this feature works and adapt it to channel follower.
Sometimes, the variable partner_id is False (on first connections). This leads to a
crash because partner_id is a boolean instead of an integer. This commits simply
sidestep the problem.
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
- im_chat.session will be replaced by mail.channel
- im_chat.shortode is renamed into mail.shortcode
- im_chat.presence is moved to bus module
- js and controller code is moved from im_chat to mail module
This commit only move files, and modify manifests, bundles, ... The code will be adapt in the next commits.
Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.
The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.
A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.
New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.
A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).
The next commit will add the various inherits necessary to add the actions
in the main addons.
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.
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
updated their code accordingly.
Subtype display in the follower widget has been improved: now displaying correctly
subtypes ordered by related model, then internal / not internal, then sequence.
Mail statistics are now stored onto a separated object (mail.mail.statistics), allowing to
handle emails separately from statistics (among other removing mail.mail entries while keeping
statistics).
Everything linnked to opened/replied/bounce is not managed by mass_mailing, removed added code
in mail module.
bzr revid: tde@openerp.com-20130913115408-322cyjipdg680as6
Added 2 fields on mail_mail to count read/bounce.
Added bounce alias bounce-mail_id-model-res_id.
Added message_receive_bounce method that try to incremetn message_bounce field.
bzr revid: tde@openerp.com-20130806151143-7dw6xlj8n7mh0nqe
Jigar Patel