recipients instead of using template-based values. This should be the default way of using
templates actually, to avoid confusion with mako, ill-defined templates, ...
email_template code has been updated to handle recipient_ids when creating an email, depending
on its generated template values or default recipients.
mail_compose_message has also been updated, delegating the calculation of recipient when
having a template to the template itself, using some context keys to force the use
of partners instead of email_to and email_cc.
Also updated email_template form view to be a bit less confusing.
bzr revid: tde@openerp.com-20140325140324-bljvybigk3zv5ugm
Local URLs are converted into absolute URLs, notably because when using the
email designer, images are added using local URLs. Previously to this fix
the template was analyzed to find local URLs and make them absolute.
However this causes 2 issues :
- mako-based URLs are broken because a scheme is added before the mako that
generated the image src
- when changing the base url, the templates are not updated
The URLs are now converted dynamically when generating the content of the
html. This is done by passing a new parameter that enable the post processing
of the generated content.
Also fixed double body generation when using templates; fields parameter
was not propagated correctly.
bzr revid: tde@openerp.com-20140304112957-l9b10gyjqphs5fgc
- fixed composer using template that were rendering the body twice, once form the template and
once from the composer body. Only the latter one is used, so avoid generating the template body
that is not necessary
- fixed email_template generating values for a set of given fields, ignoring the field list
given into parameter
- fixed post processing of templates to transform local urls into absolute urls; now urls are
transformed after body generation, when sending email based on templates , or when generating
the content when using the composer.
bzr revid: tde@openerp.com-20140227153835-gmqnxrzed9fnbxhm
Indeed its content may contain invalid html that could be stripped by the
sanitizer. The content generated based on the template will be sanitized
when stored in the mail_mail or mail_message body field, thus after
rendering.
bzr revid: tde@openerp.com-20140227144228-d275lxz6ryarkg4t
Indeed its content may contain invalid html that could be stripped by the
sanitizer. The content generated based on the template will be sanitized
when stored in the mail_mail or mail_message body field, thus after
rendering.
The template therefore holds html, but that is not sanitized. But that's
still html, therefore using an html field.
bzr revid: tde@openerp.com-20140227134829-te8mxeakc3s96fun
email_recipients is a char fields holding a comma separated list of partner_ids
that are the email recipients. This field is correctly handled in the composer
but was not taken into account in the send_mail method email_template.
However due to model limitations, this field can only be taken into account
when sending the email directly using force_send. When the email is
queued, no field is available to hold the value of email_recipients.
This is already fixed in trunk/v8 as a field has been added to handle
this value.
[FIX] mail: when sending email to some recipients_ids, filter to have only
the existing partner_ids. Trusting email template to generate valid
partner_ids is a bit risky.
[TESTS] email_template: added tests for send_mail
bzr revid: tde@openerp.com-20131220144652-h18yam60vpedbh7x
- Access Right too restrictif for user
- Bug UI between Firefox and Chrome
- Bug UI many2many_tag cursor on bullet
- Temp Fix on email_template to manage partner_to
- Manage attendee from hr_holidays
- Manage avatar_model in sidebar_items for filter (res.partner was hard coded)
- Remove quick add from HR-holiday, because some field (as day) is calculated on event "onchange"
bzr revid: jke@openerp.com-20131220141855-mbhxtr07fn0sroe0
Also refactored send_mail in mail.compose.message in order to be able to override
mail values without having to intefere with the send_mail behavior.
bzr revid: tde@openerp.com-20130828140929-xe9hbmbo6jxgs9mh
The `dateutil` package is not included directly in the globals because
`dateutil.relativedelta.relativedelta` is an old-style class and jinja2
does not appear to support instantiating old-style classes within an
expression, so `relativedelta` support is provided using a "lambda proxy".
bzr revid: odo@openerp.com-20130826124405-bixzwyhl65c7v75b
Christophe Simonis
Denis Ledoux
Martin Trigaux
Thibault Delavallée
Simon Lejeune
Olivier Dony
openerp-sle
Frédéric van der Essen
Turkesh Patel (Open ERP)
jke-openerp
chirag patel
Raphael Collet