diff --git a/addons/mail/doc/changelog.rst b/addons/mail/doc/changelog.rst
deleted file mode 100644
index 5eee5f136a6325084be922046a122b4d5808c197..0000000000000000000000000000000000000000
--- a/addons/mail/doc/changelog.rst
+++ /dev/null
@@ -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``.
diff --git a/addons/mail/doc/index.rst b/addons/mail/doc/index.rst
deleted file mode 100644
index 033b1241af634beeb52dff12639bef0b39fcfabf..0000000000000000000000000000000000000000
--- a/addons/mail/doc/index.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/index.rst.inc b/addons/mail/doc/index.rst.inc
deleted file mode 100644
index 7f56666336be4c69655bbef10bd6310357339aea..0000000000000000000000000000000000000000
--- a/addons/mail/doc/index.rst.inc
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/mail_message.rst b/addons/mail/doc/mail_message.rst
deleted file mode 100644
index de58b3bebf27b73a45d43f23183247678481883d..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_message.rst
+++ /dev/null
@@ -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.
diff --git a/addons/mail/doc/mail_needaction_howto.rst b/addons/mail/doc/mail_needaction_howto.rst
deleted file mode 100644
index 8cb41cee37488912d4b52c56902299e0c21ef141..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_needaction_howto.rst
+++ /dev/null
@@ -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']
diff --git a/addons/mail/doc/mail_openchatter_howto.rst b/addons/mail/doc/mail_openchatter_howto.rst
deleted file mode 100644
index f8b4fd989343594aaee8f5ebd222e3d3e6cd39ae..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_openchatter_howto.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/mail_partner.rst b/addons/mail/doc/mail_partner.rst
deleted file mode 100644
index a99246395d760e876e51b5f2fea2b29d346d0e7a..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_partner.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/mail_state.rst b/addons/mail/doc/mail_state.rst
deleted file mode 100644
index cf1874ffca155aeef5aafdd29e430805b854e5f6..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_state.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/mail_subtype.rst b/addons/mail/doc/mail_subtype.rst
deleted file mode 100644
index e63b67936cd8069047284eec8700dbe8f7cd09d4..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_subtype.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/mail_thread.rst b/addons/mail/doc/mail_thread.rst
deleted file mode 100644
index 9a59b7c967c78ff1abf3afcf91262c285304714e..0000000000000000000000000000000000000000
--- a/addons/mail/doc/mail_thread.rst
+++ /dev/null
@@ -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
diff --git a/addons/mail/doc/tracked_field.rst b/addons/mail/doc/tracked_field.rst
deleted file mode 100644
index 8d06ae1fa415f1e936db4b7ebb768f51b56fbeec..0000000000000000000000000000000000000000
--- a/addons/mail/doc/tracked_field.rst
+++ /dev/null
@@ -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
\ No newline at end of file