The button text colors were forced to the default link color while that
color should only be forced for links which are not buttons.

Note: this fix will not impact existing mail templates thanks to
transcoding. That's why it is possible to fix safely in stable versions.

Part of https://github.com/odoo/odoo/pull/60203
opw-2360756

closes odoo/odoo#60203

X-original-commit: 3d8c6eca5ffa657485bdf4bec84c07b4f978a71d
Related: odoo/enterprise#14178
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

*: mass_mailing, website_blog, website_forum, website_hr_recruitment

Deprecate alpha, beta, gamma, delta and espilon color names and now use
a new color system: o-color-x, with x from 1 to 5.

This will allow to review the colors of all themes to have nice visuals
for the new color combinations classes, without breaking the current
uses of bg-alpha, alert-delta, etc in current websites of customers
(by keeping the old color and classes for compatibility).

This will also allow to uniformize all themes under the same conventions
to enforce BS color override:
- o-color-1 used as primary (as before, for alpha)
- o-color-2 used as secondary (as before, for beta)

Before, some themes were not following the 2 guidelines. The users
using those themes will simply have the possibility to choose o-color-1
and o-color-2 colors accordingly to restore their website without
breaking the new system features.

Another change is that those colors are defined through color palettes
and not theme color palettes. This will avoid them to generate automatic
bootstrap classes which we don't want (alert, btn) and generate the one
we want by ourself.

Note: for mass mailing, the colors and classes also have been renamed
but the system stays unchanged.

Part of https://github.com/odoo/odoo/pull/45856
task-2197038

Changing the background color was not working
because 'o_mail_snippet_general' having a background color white.
while bg-* colors are applied on a parent of 'o_mail_snippet_general'

closes odoo/odoo#42513

X-original-commit: 751dd4c16f8e6c9e373bd9be3a783cde2833947d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Since we reverted the saas-12.2 editor in favor of the 12.0 one,
we faced a dilemna regarding how the editor iframe is handled in
mass_mailing.

The 12.0 version was using a special controller to get the website
assets required for mass_mailing while the saas-12.2 version used
a completely different mechanism that was, obviously, not handled
by the 12.0 version.

We did not want to reintroduce the old controllers who were
considered to be a hack to load the assets in the mass_mailing
iframe. However, we were very cautious about changing the editor
itself to avoid introducing new bugs in the editor core of 13.0.

The approach we chose at the end, is to use the loadAsset mechanism
introduced in saas-12.2 to load the necessary assets and inject them
in the mass_mailing iframe. This did not reintroduce the controllers
nor did it require to change the code of the editor itself. However,
it required moderate changes to the wysiwyg interface.

Part of PR 35677.

Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>

Mass mailing themes are redefining some bg-* classes their own way...
unfortunately that way was not working anymore with BS3. This commit
adapts the CSS code to solve the problem but ideally, themes should be
refactored to be more BS4 compliant.

opw-2032131

closes odoo/odoo#35333

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

* Creating a new structure by transforming all the plugins in the
  library using the odoo inheritance system. Plugins are easier to
  implement with the AbstractPlugin to add Odoo behaviors.

* From now on, the methods of the library (in this case Summernote) can
  no longer be called by other modules or files. Only the wysiwyg
  widgets can access it, to simplify the updating process. The wysiwyg
  object serves as an interface.

* Depending on the options the snippets will be loaded or not, the
  editor will be in an iframe or not... all of this is transparent from
  the outside.

* Regarding iframes, all controllers related to editing have been
  removed: the new API no longer needs them. This speeds up loading,
  eases testing and removes complexity for the same
  features.

PUBLIC FEATURES

There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
  library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
  a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
  element (option available to select all, start or end)

A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
  element
* focusInEnd: makes a focus and places the cursor at the end of the
  element
* selectContent: makes a focus and selects the content

HTML FIELD

The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
  saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
  dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
  an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
  into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
  cssEdit)
* wrapper: {template} qweb static template (containing a tag:
  id = "wrapper") that will include the content during editing (removed
  on save)

MASS MAILING

A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.

Co-authored-by: Antoine Guenet <age@odoo.com>

- Email generated from mass mailing will have its own layout with internal css.
- strip_classes is removed from mail_message because mail client are now supporting
  internal stylesheet. we need it for make mail responsive.

mail: manually removed classes from incoming mail body

Because we removed strip_classes from mail message body field because we want to
allow classes in outgoing mail to make it responsive but classes are not removed
from incoming mails so here we manually removed classes from incoming mail.

opw-1836556