- RML Reports
- Webkit Reports (most part already removed by 13b9982c)
- LocalService in netsvc.py
- rename attributes like rml_% to report_%
- rename ir.actions.report.xml to ir.actions.report
- allow rendering directly on an ir.actions.report by calling render method
- remove 'controller' report_type
- remove unused res.font stuff
- remove print_report method in models.py (not used)
- restore removed call to pdftotext process in test_reports

* Reverse wrapper courtesy of @rco-odoo's original P3 branch
* thin compat module stripped down from werkzeug (to augment as needed)

issue 8530

If the date passed is falsy, return
an empty string instead of crashing.

opw-704260

Format all the dae

Up to now, there was no possibility to format a date
within a specific language, such as the customer
language. The date was always displayed with the format
YYYY-mm-dd.
(There was for the datetime, thanks to format_tz, but
not for a simple date without time)

This revision adds this possibility, but doesn't change
the according email templates
(such as the invoice date on the invoice email template)
as it would require to update all translations, in
the .po files and on transifex.

If a user absolutely want this, he has to add
the call to `format_date` himself, manually.

opw-704260

Remove unrestricted "read" access.  To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.

Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id.  This removes the necessity of a search on `ir.model`.

Add `sudo()` to call `get_param` where necessary, and make the web client use a
controller instead of directly accessing parameters.

Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.

This commit closes #13865

This reverts commit dc02f773.

This commit caused a side-effect that is worse than the issue
it tried to fix, which was purely cosmetic.
Now in mass-mail mode the template is only rendered once
and all recipients receive the same PDF, which completely
defeats the goal of a dynamic report. We have static
attachments for that.

Original fix related to opw-657152
Reverts PR #10568

This commit is a port of a17c09af to master
The email templates may contain non-html content (mako) which should not be
sanitized.
Changing this attribute to sanitize_attributes made the translations to be split
when translated.

Now having

 * sanitize: run the sanitizer to clean the html (removing javascripts,
   unwanted tags, ...)
 * sanitize_tags: only a subset of tags is allowed in html content.
   Unwelcomed tags are remove dand their content stripped.
 * sanitize_attributes: only a subset of attributes is allowed.
 * sanitize_style: only a subset of style attributes is allowed. Style
   attributes are parsed to keep only a white list.
 * strip_style: all style is removed. It bypasses sanitize_style as there
   is no need to sanitize something that is removed.
 * strip_classes: remove class attributes

Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.

This commits adds the check W0101 to test_pylint and fixes the errors.

The index in sequence.py was added in rev 1381ac13 and cancelled a day later in 83fdc271
so i guess it is safe to remove it.

To avoid to use the context to pass additional arguments just to specify
recipients or other mail.message field values.

When using context action for a template, the report was not shown in
the compose message as an attachment.

opw:657152

The mail template rendering system use "autoescape" for subject, body,
email_to, ...

Using autoescape is good for the body, but for the subject it means
variables insertions have to be marked as safe.

This commit add another environment without autoescaping enabled for the
subject field.

From https://tools.ietf.org/html/rfc2822:

  The "Subject:" and "Comments:" fields are unstructured fields as defined
  in section 2.2.1, and therefore may contain text or folding white space.

  2.2.1. Unstructured Header Field Bodies

  Some field bodies in this standard are defined simply as "unstructured"
  (which is specified below as any US-ASCII characters, except for CR and
  LF) with no further restrictions.

closes #10547

opw-659231
opw-666801
opw-665863

When editing an email template with the wysiwyg,
the `<` and `>` operators are automatically converted
to `&lt;` and `&gt;`, even for the Jinja2 conditions,
therefore breaking these conditions, and the render
of the email templates.

We avoid to use these operators in the email
template, so users can customize the notification
email template without having an advanced
knowledge on how to edit an email template containing
Jinja2 code.

Besides, the line return at the end of the email template,
just after the `% endif`,
is done on purpose as well: the wysiwyg adds automatically,
at the time of this revision,
`<p></p>` at the end of the email template source, but
this cannot be added on the same line than `% endif`,
otherwise this is considered as Jinja2 code, and it's not.

opw-659113

Did you missed me? That was a big one.

And use this new features to send the email template defined in the last commit
on the module installation.

Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.

The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.

A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.

New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.

A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).

The next commit will add the various inherits necessary to add the actions
in the main addons.

more menu action linked to an email template.

[TESTS] mail: added a test for this method.

New api take (record, timestamp) as param.
So cr was the record, and uid the timestamp...

- do not browse a browse record
- removed onchange from the form view, as they are managed directly by the new API

templates that have a void email_from, just fall back on the default email_from
defined on the mail_message model.

example) crashed because of a bad management of void res_ids.

Unify and refactor exception handling in framework and addons.

The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
 - `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
 - `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
 - `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
 - `MissingError`: raised when an operation is attempted on a record that does not exist.
 - `ValidationError`: raised when an operation violates a SQL or Python constraint.
 - All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.

All exceptions take a single message argument.

The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.

A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.

This commit introduces a more consistent policy for logging errors and warnings:
 - All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
 - All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
 - All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.

1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements

Let 2015 be a year without modelines!
cf #4174

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

append_content_to_html expects two strings. If the user has no signature, it returns user.signature returns False