Previous implementation did a search on mail.followers with subtype_ids=False, leading
to a very bad computation time. This search is now avoided.
bzr revid: tde@openerp.com-20130613082029-lmd63s3mqwxasy4j
mail.compose.message wizard and messaage_process now check that the active model
has message_post defined. Otherwise using thread_model context key that is better
managed in message_post, it is possible to use mail_thread.message_post() with a
thread_model and thread_id that should not allow message_post otherwise.
Hint: look for backport into 7.0
bzr revid: tde@openerp.com-20130606123230-d7ql14yydzfrlc7h
Check only aliases that effectively create new records (not aliases used for updating).
When having several possible aliases, do not display any alias, because we do not have
any information about the correct alias to display.
bzr revid: tde@openerp.com-20130530124128-w7lz1jsrspyu38dv
[FIX] mail, project, project_issue, crm_lead: fixed 'XX Created' subtype not triggered because of condition
based on state=new and not state=draft.
For tasks, issues and leads, no generic 'Document created' message is posted anymore
because of the 'XX Created' message with subtype automatically logged.
Generic creation message is logged before automatic subscription to enable
message pushing to responsibles.
bzr revid: mat@openerp.com-20130529143022-wy76srwb2nwkspe3
based on state=new and not state=draft.
For tasks, issues and leads, no generic 'Document created' message is posted anymore
because of the 'XX Created' message with subtype automatically logged.
Generic creation message is logged before automatic subscription to enable
message pushing to responsibles.
bzr revid: tde@openerp.com-20130529131458-9709ffrsy479hwy3
[FIX] mail_message, mail, project, task, issue: it is now possible to have model-specific access rule checking for mail.message related acces right / rules. Task and issue allow to create mail.message when the user has a read access on the related document, not only when having write access.
bzr revid: tde@openerp.com-20130528144447-3ivcom6r9x7q949b
The way attachments are linked to the document has been cleaned. Posting method message_post may receives 2 arguments:
- attachment_ids: those linked to the wizard model (mail.compose.message) are linked to the document (res_model, res_id)
- attachments: the tuples are used to create new attachments linked to the document
The wizard does not set the res_model and res_id of attachments anymore, delegating this job to message_post.
The mail.message and mail.compose.message now use their respective attachment_ids field when possible. This is done instead of reading/creating new attachments based on the attachments tuple each time a mail.compose.message is processed. Email templates now also use attachment_ids, in particular when generating emails, instead of using the attachments tuple. Only reports are still generated on the fly and put into attachments instead of attachment_ids.
A cron job has been added to unlink 'lost' attachments. Those are attachments:
- linked to 'mail.compose.message'
- with res_id=0 (due Chatter used in minimal mode or reports generated by templates before the wizard has an ID)
- with no activity for more than one day (create_date and write_date)
bzr revid: tde@openerp.com-20130411112033-mqph9vjlcjkoolfs
Document created text was not translatable
Subtype was fetched without context, therefore not translated
Removed odd override of _t introduced in mail_followers at revision 7885
bzr revid: tde@openerp.com-20130408092447-3ri41v6xluuj0wha
Before trying to find possible routes, check that the incoming email's
message_id is not already present in mail.message table.
If it is the case, return False.
Parsing of the message has been moved before routing, to avoid looking
for routes for emails we will discard.
Tests have been added and updated.
bzr revid: tde@openerp.com-20130322124809-ven2p5kxpqfjqxb5
The mailgateway tries to find a partner that is also an user with the email_from.
If none is found, it takes the first partner with matching email.
In message_post, it tries to find the author based on the document's followers.
Indeed it is very likely that an answer comes from a follower of a document.
The whole process is not done inside the mailgateway because document
and followers related stuff belong to message_post, not to the mail gateway.
Tests have been added in mail.
bzr revid: tde@openerp.com-20130321120451-qk524qayq28sw3th
Christophe Simonis
Thibault Delavallée
Denis Ledoux
Martin Trigaux
Olivier Dony
Raphael Collet
Quentin (OpenERP)
Christophe Matthieu
Chris Biersbach
ajay javiya (OpenERP)