Skip to content
Snippets Groups Projects
Unverified Commit 0c8f3038 authored by Damien Bouvy's avatar Damien Bouvy
Browse files

[IMP] mail: remove deprecated doc

parent e0cbb058
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 478 deletions
addons/mail/doc/changelog.rst deleted 100644 → 0
+ 0
− 26
View file @ e0cbb058
.. _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``.
addons/mail/doc/index.rst deleted 100644 → 0
+ 0
− 12
View file @ e0cbb058
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
addons/mail/doc/index.rst.inc deleted 100644 → 0
+ 0
− 23
View file @ e0cbb058
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
addons/mail/doc/mail_message.rst deleted 100644 → 0
+ 0
− 111
View file @ e0cbb058
.. _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.
addons/mail/doc/mail_needaction_howto.rst deleted 100644 → 0
+ 0
− 15
View file @ e0cbb058
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']
addons/mail/doc/mail_openchatter_howto.rst deleted 100644 → 0
+ 0
− 112
View file @ e0cbb058
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
addons/mail/doc/mail_partner.rst deleted 100644 → 0
+ 0
− 10
View file @ e0cbb058
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
addons/mail/doc/mail_state.rst deleted 100644 → 0
+ 0
− 28
View file @ e0cbb058
.. _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
addons/mail/doc/mail_subtype.rst deleted 100644 → 0
+ 0
− 70
View file @ e0cbb058
.. _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
addons/mail/doc/mail_thread.rst deleted 100644 → 0
+ 0
− 53
View file @ e0cbb058
.. _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
addons/mail/doc/tracked_field.rst deleted 100644 → 0
+ 0
− 18
View file @ e0cbb058
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
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment