[IMP] mail: remove deprecated doc
This commit is contained in:
Damien Bouvy
@@ -1,26 +0,0 @@
|
||||
.. _changelog:
|
||||
|
||||
Changelog
|
||||
=========
|
||||
|
||||
`trunk (saas-2)`
|
||||
----------------
|
||||
|
||||
- ``mass_mailing_campaign`` update
|
||||
|
||||
- ``mail_mail`: moved ``reply_to`` computation from ``mail_mail`` to ``mail_message``
|
||||
where it belongs, as the field is located onto the ``mail_message`` model.
|
||||
- ``mail_compose_message``: template rendering is now done in batch. Each template
|
||||
is rendered for all res_ids, instead of all templates one id at a time.
|
||||
- ``mail_thread``: to ease inheritance, processing of routes is now done in
|
||||
message_route_process, called in message_route
|
||||
|
||||
- added support of ``active_domain`` form context, coming from the list view.
|
||||
When checking the header hook, the mass mailing will be done on all records
|
||||
matching the ``active_domain``.
|
||||
- added ``mail_server_id`` to mail_message, removing it from mail_mail. This allows
|
||||
to set the preferred mail server to use for notifications emails, when using
|
||||
templates.
|
||||
- added ``_mail_post_access`` attribute that specifies the access right that
|
||||
should have the user in order to post a new message on a given model. Values
|
||||
are ``read`` (portal documents), ``write`` (default value), ``unlink`` or ``create``.
|
||||
@@ -1,12 +0,0 @@
|
||||
Mail module documentation
|
||||
=========================
|
||||
|
||||
The Mail module holds all models and logic related to messages management. At low-level, it handles messages and offers an API to message queues for email sending. At an higher level, it provides the OpenChatter feature that is a thread management system inside OpenERP. A model that inherits from the mail module adds OpenChatter to its document. Its gives them the following capabilities :
|
||||
|
||||
- messages management with a threaded design
|
||||
- subscription mechanism tha allow users to follow/unfollow documents
|
||||
- notifications mechanism; notifications are pushed to users to form a Wall page holding the latest pushed messages
|
||||
|
||||
The mail module also comes with an email composition wizard, along with discussion groups.
|
||||
|
||||
.. include:: index.rst.inc
|
||||
@@ -1,23 +0,0 @@
|
||||
|
||||
Mail Module documentation topics
|
||||
'''''''''''''''''''''''''''''''''
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
mail_message
|
||||
mail_thread
|
||||
mail_openchatter_howto
|
||||
mail_needaction_howto
|
||||
mail_partner
|
||||
mail_state
|
||||
mail_subtype
|
||||
|
||||
|
||||
Changelog
|
||||
'''''''''
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
changelog.rst
|
||||
@@ -1,111 +0,0 @@
|
||||
.. _mail_message:
|
||||
|
||||
mail.message
|
||||
============
|
||||
|
||||
Models
|
||||
++++++
|
||||
|
||||
``mail.message`` is a class for holding the main attributes of a message object
|
||||
(notification for system message, reciving email message or sent messages). It
|
||||
could be reused as parent model for any database model, wall thread view, or
|
||||
wizard screen that needs to hold a kind of message.
|
||||
|
||||
All internal logic should be in a database-based model while this model
|
||||
holds the basics of a message. For example, a wizard for writing emails
|
||||
should inherit from this class.
|
||||
|
||||
|
||||
.. versionchanged:: 7.0
|
||||
|
||||
ClientAction (ir.actions.client)
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<record id="mail_message_action_inbox" model="ir.actions.client">
|
||||
<field name="name">Inbox</field>
|
||||
<field name="tag">mail.wall</field>
|
||||
<field name="res_model">mail.message</field>
|
||||
<field name="context"></field>
|
||||
<field name="params"></field>
|
||||
<field name="help" type="html"></field>
|
||||
</record>
|
||||
|
||||
- ``tag`` : 'mail.wall', 'mail_thread' or 'mail.widget'
|
||||
'mail.wall' to have a display like the mail wall with threads, title, search view
|
||||
(default value like a wall)
|
||||
'mail_thread' widget for field on standard view. (default value like a thread for
|
||||
record, view on flat mode, no reply, no read/unread)
|
||||
'mail.widget' it's the root thread, used by 'mail.wall' and 'mail_thread'
|
||||
|
||||
- ``help`` : Text HTML to display if there are no message
|
||||
- ``context`` : insert 'default_model' and 'default_res_id'
|
||||
- ``params`` : options for the widget
|
||||
- ``domain`` : choose the domain of the messages
|
||||
- ``truncate_limit`` : {Number} number of character to display before having a "show more"
|
||||
link; note that the text will not be truncated if it does not have 110% of the parameter
|
||||
- ``show_record_name`` : {Boolean} display the name and link of the related record
|
||||
- ``show_reply_button`` : {Boolean} display the reply button
|
||||
- ``show_read_unread_button`` : {Boolean} display the read/unread button
|
||||
- ``display_indented_thread`` : {int [0,1]} number thread level to indented threads.
|
||||
- ``show_compose_message`` : display the composer on top thread
|
||||
- ``show_compact_message`` : display the compact message on the thread when the user clic
|
||||
on this compact mode, the composer is open
|
||||
- ``message_ids`` : {Array | False} List of ids to fetch by the root thread. If no value,
|
||||
the root search the message by the domain
|
||||
- ``compose_placeholder`` : Message to display on the textareaboxes.
|
||||
- ``show_link`` : Display partner (authors, followers...) on link or not
|
||||
- ``compose_as_todo`` : The root composer mark automatically the message as todo
|
||||
- ``readonly`` : Read only mode, hide all action buttons and composer
|
||||
|
||||
Fields
|
||||
++++++
|
||||
|
||||
- ``type`` : usually 'email', 'comment', 'notification'.
|
||||
Message type: email for external email message recieve, notification for system
|
||||
message, comment for other messages such as user replies.
|
||||
- ``subtype_id`` :
|
||||
Subtype of the notification for system message. The users can followe a document
|
||||
and choose the subtype of this document (eg: Create, Comment, Done).
|
||||
You can defined new subtypes and choose his name, by agreement the id begin by "mt\_" on the model
|
||||
"mail.message.subtype".
|
||||
- ``partner_ids`` :
|
||||
List of recipients, the recipients have this message in their personal mailboxe.
|
||||
- ``notified_partner_ids`` :
|
||||
Partners that have a notification pushing this message in their mailboxes. Usualy
|
||||
it's an automatic system message for a model followed by users.
|
||||
- ``notification_ids`` :
|
||||
Technical field holding the message notifications. Use notified_partner_ids to access
|
||||
notified partners.
|
||||
- ``attachment_ids`` :
|
||||
List of attachments
|
||||
- ``parent_id`` :
|
||||
It's the initial thread message. It's use for group message by thread in mailboxes.
|
||||
- ``child_ids`` :
|
||||
List of child message linked to the initial thread message.
|
||||
- ``model`` :
|
||||
Related Document Moded. It's use for group message by document.
|
||||
- ``res_id`` :
|
||||
Related Document ID. It's use for group message by document.
|
||||
- ``record_name`` :
|
||||
Functionnal field use to get the name of related document.
|
||||
- ``vote_user_ids`` :
|
||||
List of partner that vote/like this message.
|
||||
- ``to_read`` :
|
||||
Functional field to search for messages the current user has to read. The messages as
|
||||
treat like a need action. When the user recive a message (to_read = True) this message
|
||||
or action must be performed and mark done (to_read = False)
|
||||
- ``favorite_user_ids`` :
|
||||
Users that set this message in their favorites/todo list.
|
||||
|
||||
Methods
|
||||
+++++++
|
||||
|
||||
- ``message_read`` :
|
||||
Value: ids, domain, message_unload_ids, thread_level, context, parent_id, limit
|
||||
Return: List of dictinary of message. All message is sent with their parented messages and
|
||||
sort by id. The messages that the user can read but not in his search, are group in
|
||||
expandable messages. The expandable messages contain the domain to expand.
|
||||
- ``check_access_rule`` :
|
||||
Overwrite the initial message for this model.
|
||||
@@ -1,15 +0,0 @@
|
||||
|
||||
How to use the need action mechanism in my addon
|
||||
=================================================
|
||||
|
||||
Make your module inheriting from ir.needaction_mixin class
|
||||
|
||||
Feature integration
|
||||
++++++++++++++++++++
|
||||
|
||||
::
|
||||
|
||||
class my_module(osv.osv):
|
||||
_name = "my.module"
|
||||
_description = "My Module"
|
||||
_inherit = ['ir.needaction_mixin']
|
||||
@@ -1,112 +0,0 @@
|
||||
|
||||
How to use OpenChatter in my addon
|
||||
===================================
|
||||
|
||||
Running example
|
||||
++++++++++++++++
|
||||
|
||||
A small my_task model will be used as example to explain how to use the
|
||||
OpenChatter feature. Being simple, it has only the following fields:
|
||||
|
||||
- a name
|
||||
- a task responsible
|
||||
- a related project
|
||||
|
||||
::
|
||||
|
||||
class my_task(osv.osv):
|
||||
_name = "my.task"
|
||||
_description = "My Task"
|
||||
_columns = {
|
||||
'name': fields.char('Name', required=True, size=64),
|
||||
'user_id':fields.many2one('res.users', string='Responsible',
|
||||
ondelete='cascade', required=True, select=1),
|
||||
'project_id':fields.many2one('project.project', string='Related project',
|
||||
ondelete='cascade', required=True, select=1),
|
||||
}
|
||||
|
||||
|
||||
Two-lines feature integration
|
||||
++++++++++++++++++++++++++++++
|
||||
|
||||
Make your object inherit from :class:`mail.thread`::
|
||||
|
||||
class my_task(osv.osv):
|
||||
_name = "my.task"
|
||||
_description = "My Task"
|
||||
# inherit from mail.thread allows the use of OpenChatter
|
||||
_inherit = ['mail.thread']
|
||||
|
||||
Use the thread viewer widget inside your form view by using the mail_thread
|
||||
widget on the message_ids field inherited from :class:`mail.thread`::
|
||||
|
||||
<record model="ir.ui.view" id="my_task_form_view">
|
||||
<field name="name">My Task</field>
|
||||
<field name="model">my.task</field>
|
||||
<field name="priority">1</field>
|
||||
<field name="arch" type="xml">
|
||||
<form>
|
||||
[...]
|
||||
<field name="message_ids" colspan="4" widget="mail_thread" nolabel="1"/>
|
||||
</form>
|
||||
</field>
|
||||
</record>
|
||||
|
||||
Send notifications
|
||||
+++++++++++++++++++
|
||||
|
||||
When sending a notification is required in your workflow or business logic,
|
||||
use :meth:`mail.thread.message_post`. It will automatically take care of
|
||||
subscriptions and notifications.
|
||||
|
||||
Here is a small example of sending a notification when the ``do_something``
|
||||
method is called::
|
||||
|
||||
def do_something(self, cr, uid, ids, context=None):
|
||||
self.do_something_send_note(cr, uid, ids, context=context)
|
||||
return res
|
||||
|
||||
def do_something_send_note(self, cr, uid, ids, context=None):
|
||||
self.message_post(
|
||||
cr, uid, ids, _('My subject'),
|
||||
_("has received a <b>notification</b> and is happy for it."),
|
||||
context=context)
|
||||
|
||||
Notifications guidelines
|
||||
+++++++++++++++++++++++++
|
||||
|
||||
- avoid unnecessary content, swamping users with irrelevant messages will lead
|
||||
to them ignoring all messages
|
||||
- use short sentences
|
||||
- do not include the document name, this is done by the thread widget
|
||||
- use a simple and clean style
|
||||
|
||||
- html tags are supported: use <b> or <em> mainly
|
||||
- put key word(s) in bold
|
||||
- avoid fancy styles that will break the OpenERP look and feel
|
||||
- create a separate method for sending your notification, use clear method
|
||||
names allowing quickly spotting notification code e.g. name notification
|
||||
methods by using the original method name postfixed by ``_send_note``
|
||||
(``do_something`` -> ``do_something_send_note``)
|
||||
|
||||
Subscription management
|
||||
++++++++++++++++++++++++
|
||||
|
||||
The default subscription behavior is the following:
|
||||
|
||||
* Subscriptions are set up by creating a :class:`mail.followers`` entry
|
||||
* If a user creates or updates a document, they automatically follow it. The
|
||||
corresponding :class:`mail.followers` entry is created
|
||||
* If a user explicitly cliks on the document's :guilabel:`Follow` button,
|
||||
they follow the document. The corresponding :class:`mail.followers` entry
|
||||
is created
|
||||
* If a user explicitly clicks on the document's :guilabel:`Unfollow` button,
|
||||
they stop following the document. The corresponding :class:`mail.followers`
|
||||
entry is deleted
|
||||
|
||||
You should not directly manipulate :class:`mail.followers` entry, if you need
|
||||
to override the default subscription behavior you should override the relevant
|
||||
:class:`mail.thread` methods.
|
||||
|
||||
.. TODO: wtf are the relevant mail.thread methds? message_get_subscribers
|
||||
has disappeared and nothing looks like a replacement
|
||||
@@ -1,10 +0,0 @@
|
||||
What is shown
|
||||
==============
|
||||
- for every module which are related to partner show apporopriate message in the partner view like opportunities, sale orders and invoices.
|
||||
|
||||
|
||||
How it is done
|
||||
===============
|
||||
- _inherit = 'mail.thread'
|
||||
|
||||
- Override def message_load_ids(self, cr, uid, ids, limit=100, offset=0, domain=[], ascent=False, root_ids=[], context=None) search by the partner
|
||||
@@ -1,28 +0,0 @@
|
||||
.. _mail_state:
|
||||
|
||||
message_unread
|
||||
==============
|
||||
|
||||
``message_unread`` is a boolean field that states whether the document
|
||||
has unread messages. In previous versions, some documents were going
|
||||
back to ``pending`` state when receiving an email through the mail
|
||||
gateway. Now the state related to messages differs from the state or
|
||||
stage of the document itself.
|
||||
|
||||
message_unread and need action mechanism
|
||||
++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
The ``mail`` module introduces a default behavior for the need_action
|
||||
mechanism [REF].
|
||||
|
||||
::
|
||||
|
||||
def get_needaction_user_ids(self, cr, uid, ids, context=None):
|
||||
""" Returns the user_ids that have to perform an action
|
||||
:return: dict { record_id: [user_ids], }
|
||||
"""
|
||||
result = super(ir_needaction_mixin, self).get_needaction_user_ids(cr, uid, ids, context=context)
|
||||
for obj in self.browse(cr, uid, ids, context=context):
|
||||
if obj.message_unread == False and obj.user_id:
|
||||
result[obj.id].append(obj.user_id.id)
|
||||
return result
|
||||
@@ -1,70 +0,0 @@
|
||||
.. _mail_message_subtype:
|
||||
|
||||
OpenChatter Pi (3.1415): Message Subtype
|
||||
========================================
|
||||
|
||||
To overcome the problems of crowdy walls in system notification, We have added features of **Message Subtype** in mail.
|
||||
|
||||
mail.message.subtype
|
||||
++++++++++++++++++++
|
||||
``mail.message.subtype`` has following fields:
|
||||
|
||||
- ``Name``: fields.char(' Message Subtype ', size = 128,required = True,help = 'Subtype Of Message'),
|
||||
- ``model_ids``: fields.many2many('ir.model','mail_message_subtyp_message_rel','message_subtype_id', 'model_id', 'Model',help = "link some subtypes to several models, for projet/task"),
|
||||
- ``default``: fields.boolean('Default', help = "When subscribing to the document, users will receive by default messages related to this subtype unless they uncheck this subtype"),
|
||||
|
||||
mail.followers
|
||||
++++++++++++++
|
||||
|
||||
In ``mail.followers`` we have added additional many2many field subtype ids :
|
||||
|
||||
- ``subtype_ids``: fields.many2many('mail.message.subtype','mail_message_subtyp_rel','subscription_id', 'subtype_id', 'Subtype',help = "linking some subscription to several subtype for projet/task")
|
||||
|
||||
mail.message
|
||||
++++++++++++
|
||||
|
||||
In mail_message we have added additional field subtype_id which Indicates the Type of Message
|
||||
|
||||
- ``subtype_id``: fields.many2one('mail.message.subtype', 'Subtype')
|
||||
|
||||
mail.thread
|
||||
+++++++++++
|
||||
|
||||
- In **message_post** method add the *subtype_id* field as parameter and set as default subtype 'Other'.
|
||||
|
||||
def message_post(self, cr, uid, thread_id, body='', subject=False, msg_type='notification', parent_id=False, attachments=None, subtype='other', context=None, ``**kwargs``):
|
||||
|
||||
- In **message_subscribe** method add the *subtype_ids* field as parameter.In this method if subtype_ids is None, it fatch the default true subtypes in mail.message.subtypes otherwise pass selected subtypes.
|
||||
For update subtypes call **message_subscribe_udpate_subtypes** method
|
||||
|
||||
def message_subscribe(self, cr, uid, ids, partner_ids,subtype_ids = None, context=None):
|
||||
|
||||
- Add **message_subscribe_udpate_subtypes** method to update the subtype_ids in followers.
|
||||
|
||||
def message_subscribe_udpate_subtypes(self, cr, uid, ids, user_id, subtype_ids,context=None):
|
||||
followers_obj = self.pool.get('mail.followers')
|
||||
followers_ids = followers_obj.search(cr, uid, [('res_model', '=', self._name), ('res_id', 'in', ids)])
|
||||
return followers_obj.write(cr, uid, followers_ids, {'subtype_ids': [(6, 0 , subtype_ids)]}, context = context)
|
||||
|
||||
For Each Addons:
|
||||
++++++++++++++++
|
||||
|
||||
- Add data of subtypes for each addons module.
|
||||
- Add subtype field as parameter in **message_post** Method for each addons module.
|
||||
|
||||
How It Works:
|
||||
+++++++++++++
|
||||
|
||||
- In addons module when we Follow a Perticular document It display under the followers button.
|
||||
- In sybtypes there are 3 default subtypes for each addons
|
||||
1) Email
|
||||
2) Comment
|
||||
3) Other
|
||||
- In document display a default subtypes(which are true) related a perticular model_ids wise.
|
||||
|
||||
Example:-
|
||||
If I have open crm.lead, It display only subtypes of crm.lead
|
||||
|
||||
- When we select subtype it update subtype_ids(which are checked) in mail.follower where match res_model & res_id of the current documents.
|
||||
- when message created update subtype_id of that message in mail.message.
|
||||
- In Feeds display only those notifications of documents which subtypes are selected
|
||||
@@ -1,53 +0,0 @@
|
||||
.. _mail_thread:
|
||||
|
||||
===========================
|
||||
mail.thread and OpenChatter
|
||||
===========================
|
||||
|
||||
API
|
||||
===
|
||||
|
||||
Writing messages and notifications
|
||||
----------------------------------
|
||||
|
||||
``message_append``
|
||||
|
||||
Creates a new mail.message through message_create. The new message is attached
|
||||
to the current mail.thread, containing all the details passed as parameters.
|
||||
All attachments will be attached to the thread record as well as to the
|
||||
actual message.
|
||||
|
||||
This method calls message_create that will handle management of subscription
|
||||
and notifications, and effectively create the message.
|
||||
|
||||
If ``email_from`` is not set or ``type`` not set as 'email', a note message
|
||||
is created (comment or system notification), without the usual envelope
|
||||
attributes (sender, recipients, etc.).
|
||||
|
||||
mail.group
|
||||
++++++++++
|
||||
|
||||
A mail_group is a collection of users sharing messages in a discussion group. Group users are users that follow the mail group, using the subscription/follow mechanism of OpenSocial. A mail group has nothing in common wih res.users.group.
|
||||
Additional information on fields:
|
||||
|
||||
- ``member_ids``: user member of the groups are calculated with ``message_get_subscribers`` method from mail.thread
|
||||
- ``member_count``: calculated with member_ids
|
||||
- ``is_subscriber``: calculated with member_ids
|
||||
|
||||
res.users
|
||||
+++++++++
|
||||
|
||||
OpenChatter updates the res.users class:
|
||||
- it adds a preference about sending emails when receiving a notification
|
||||
- make a new user follow itself automatically
|
||||
- create a welcome message when creating a new user, to make his arrival in OpenERP more friendly
|
||||
|
||||
|
||||
Misc magic context keys
|
||||
+++++++++++++++++++++++
|
||||
|
||||
- mail_create_nosubscribe: when creating a new record that inherit from mail_thread,
|
||||
do not subscribe the creator to the document followers
|
||||
- mail_create_nolog: do not log creation message
|
||||
- mail_notify_noemail: do not send email notifications; partners to notify are
|
||||
notified, i.e. a mail_notification is created, but no email is actually send
|
||||
@@ -1,18 +0,0 @@
|
||||
Tracked fields
|
||||
---------------
|
||||
Tracked fields is generic logging system for the changes applied to some fields in open chatter.
|
||||
- In the definition of a fields. you have to simply add tracked=True.
|
||||
- When changing one of the fields having tracked=True on saved automatically write a log in openchatter for the changes in fields.
|
||||
|
||||
How it works:
|
||||
+++++++++++++
|
||||
- You have to add tracked=True in field defination as following.
|
||||
- ``'stage_id': fields.many2one('project.task.type', 'Stage',tracked=True),``
|
||||
- For developed this feature we override write method of mail_thread.
|
||||
- And make one mako template which shows old field and updated field.
|
||||
|
||||
Open chatter log:
|
||||
+++++++++++++++++
|
||||
- After changing field follower can show log of tracked field in open chatter as followed.
|
||||
- Updated Fields:
|
||||
- Stage: Analysis -> Specification
|
||||
Reference in New Issue
Block a user