Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes#21921.
First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
This commit improves common classes and add helpers for mail tests.
Future commits will use this new stuff to improve the tests.
* improve existing models and add some of them. There are now several
models
* mail.test.simple: chatter-enabled record without any really advanced
feature. Can be used everywhere standard chatter and communication
tests are required;
* mail.test.track: chatter-enabled record with basic value tracking
and responsible tracking;
* mail.test.activity: chatter-enabled record using activities;
* mail.test.full: complete chatter-enabled record with advanced
tracking, automatic subscription and automatic email send based on
templates and tracking;
* mail.test: chatter-enabled record having an alias. It can be used
where umbrella record like projects or teams has to be used in
tests;
* add MockEmails test class: this class mocks the mail gateway so that
tests can work on emails without actually sending them. It is taken
out of TestMail class to clearly separate features from class;
* improve created data in the various classes and prepare work to
lessen created data during tests;
* add helpers on base test class, notably
* sudoAs: context manager to run a code snippet using a given user;
* assertNotifications: assert notification content, aka Inbox or email
notification and their content; may be subject to change depending on
mail evolution;
* assertEmails: check content of sent emails;
This commit improve the daily use of activities by delegating activities
management to the document. Activities are already managed on document
through the UI either in form view or in kanban view.
Currently almost all mail tests run on mail.channel model. Indeed it is
the only model inheriting from mail.thread and mail.alias when having only
mail installed. However channel model have several specific features and
is not totally a standard mail.thread model. For example notification
recipients are computed a bit differently.
Since 4f9105a4ef mail module has a test
model allowing to perform tests on a very simple mail.thread-like model.
This commit make mail tests use this test model instead of mail.channel
everywhere it is possible. Channel model should be used only when tests
are channel-dependent.
This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
It was allowed for all employees to read, create and edit
mail aliases. Only the deletion was prevented.
Nevertheless, giving the possibility to rename a mail alias
is allmost seen as a deletion, as you can rename it to something
that just won't be used anymore. Therefore, we can consider
to give any employees the rights to delete mail aliases.
Besides, not allowing the unlink leads to issues when the
mail alias is associated to a record the user wants to delete.
He was able to create the record, and its mail aliases, but
he could not remove the record, as he was not allowed to remove
the mail alias.
For instance, an HR officer was able to create a job position,
with its mail alias, but couldn't remove the job position he created.
Closes#8466
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
In method `user_has_groups`, make "Technical Features" effective in debug mode.
Make the group "Employees" inherit "Technical Features".
Make the group "Technical Features" invisible in the user form view.
Remove useless `ir.rule` attached on group "Technical Features".
Fix `test_acl` by avoiding the tricks around the group "Technical Features".
Main changes :
- mail.notification model is removed. People do not receive notifications
anymore. Instead two ways of following documents exist
- using a channel; messages will be displayed on the channel itself
in a near future commit
- following with its partner; messages will all be considered as
needaction, using a new m2m table. People should receive less
needaction messages by following less records by themselves.
There is no more read / unread state anymore. Instead only needaction
messages are considered. Todo (Favorites) messages still exist, and are
stores on a new m2m table instead of using decorated notifciations.
- the main filter for documents is not message_unread anymore, but
message_needaction. A lot of views and filters have been updated
accordingly.
- the vote feature has been removed
Some features from live_chat have been moved to the mail module :
- channels now have members, replacing followers;
- a decorated m2m is used to link channels and members. It stores the last
seen message on the channel for a specific partner;
- channels do not create menu entries anymore, because the
NewChatter will have its own display and use of channels;
- access rights have been updated accordingly, using members instead of
followers
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.
model has been renamed to mail.channel to prepare the slack modeling.
In future commits the mail.group model will be merged with the channel
model from im_chat. The first move is to rename mail.group into
mail.channel to have a model that will unite both features.
Starting from now, subtypes can be internal. This means that only employees
(group_user members) can see the messages with this subtype. This feature
replaces and enhances the 'log a note = no subtype = internal only'
feature.
Public and portal users cannot see internal messages. This allows to have
subtypes and a follow mechanism that works for employees and is not
visible for external people.
Its first use will be for Crm Activities, allowing to have custom
subtypes visible only for salesman and not send to the customer.
This commit introduces a new view type, the timeline view. This view is
intended to display messages like the previous chatter. This is now a view
like the form or list view. Like other views it will be possible to have
custom templates for some specific needs, allowing customization.
[IMP] mail: the value tracking is modified. Previously messages were created
containing the modified values. Those values are now stored, using a new
model mail.tracking.value. The message body is dynamically build based on
the values. Tests have been updated.
This version is temporary. Indeed two main modifications will come in a short
future :
- the new design will improve the display
- the slack mode will change the way the Inbox and notifications are managed
All glory to the Hypnotoad.
Special thanks to Valerie Pirenne (vpi), Jerome Maes (jem) and Richat Mathot
(rim) that did not code but said a lot of things. Martin Trigaux (mat) did
nothing, a bit like for the slides modules, but he is busy sending emails.
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
ir.rule records are in noupdate data blocks to let the admin
alter them without fear of them being reset at next update.
Other records such as groups are in normal mode, so they
can be updated whenever necessary
bzr revid: odo@openerp.com-20121218232001-t425t4hi7qbmsip2
Mathieu Duckaerts-Antoine