Format_tz allow to format a date, but if the format was '%B', it was always January regardless lang in context
Now, it possible to use babel, to get the date in the customer language.
So:
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'fr_BE'})
will return '5/01/16 22:20'
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'en_US'})
will return '1/5/16, 10:20 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'en_US})
will return 'Jan 5, 2016, 10:20:31 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'fr_BE'})
will return '5 janv. 2016 22:20:31'
When composing an email based on an email template, some parts of the template
(the result of name_get on fields) were not translated.
This was due to missing language in context when rendering the template.
Fixes#3708, opw 617309
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
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