Before this commit, the company specific colors and font were
implemented by systematically overwriting a "virtual" report SCSS
asset file before rendering each report.
This caused many issues, forced frequent asset bundles recomputations
(performance problem + cache invalidation causing random bugs).
And it could simply not work in a multi-company setup where multiple
styles are involved, as the asset management could be made not
thread-safe.

PR #44225 was a first attempt to mitigate the numerous problems by
making the asset bundle invalidation less frequent. But the problems
were still present and a more complete solution was necessary for
multi-company setups.

Besides, the design of the bundle forbade making company specific assets.

This commit uses a different approach: instead of having a
company-specific asset that needs to be constantly updated, a global
"multi-company" asset is maintained and included in the report assets.
It only needs to be generated when a company style changes, not for
every rendering operation.

Unfortunately this change cannot be fully performed without updating the
template declarations, so it will require an update of the `web` (or
`base`) module to be operational.

As this represents a rather invasive change in a stable branch, extensive
testing was conducted to minimize the effects and ensure proper
degradation of features for production deployments where the new code
would be deployed without forcing an update of the `web` module:
- The report SCSS files were left untouched, to prevent any bundle
  invalidation, ensuring that old cached assets would remain valid. This
  means that single-company setups should not see any visible difference
  after pulling the code (with or without updating `web`).
  SCSS cleanup will be done later.
- Existing Python methods were kept but emptied, to make sure that
  old templates and code would not crash.
- For multi-companies, the last used colors will be applied for all
  reports until the `web` module is updated. The old behavior was not
  working correctly anyways, so the degradation is actually limited.
- For all setups, changing the colors after deploying this patch will
  have no effect unless the `web` module is updated.

/UPDATED FOR master on top of #44393/:
- removed the `res_company.update_scss()` method entirely
- fixed the report SCSS styles, as the variable names referred to the old
  behavior, e.g. "$o-company-primary-color" is nonsense.
  Renamed to "$o-default-report-primary-color" etc.

--
Improves #44225
Forward of #44393

opw-2168623
opw-2171040

closes odoo/odoo#46647

X-original-commit: a5b1421aecf27b1de408434d3bb6d7ac81f57dc3
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.

The following company settings are editable with that wizard:

- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.

- Set company **logo**:
Changes the company logo.

- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.

- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.

- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**

Co-authored by: Julien Mougenot <jum@odoo.com>

closes odoo/odoo#33863

Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>


Co-authored-by: Lucas Perais <lpe@odoo.com>

The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.

Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).

Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later

Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.

Fixes odoo/odoo#32228
Fixes odoo/odoo#21781

Following BS4 migration and adding sections and notes.

=====

Document templates:

- Remove margin from <p> in "informations" to allow them to be
	correctly centered vertically on their container.

- Also add a mt- and mb- on their <div> to better handle them going to a new
	line when there are too many of them.

- Add class for section and note to be able to customize them in layouts.

- Add class for price_total to be able to customize it in layouts instead
	of relying on :last-child.

- Add "page-break-inside: avoid;" on the "total" table to not split it
	between pages when it can be avoided.

- Fix sale report template "Informations" to use col-auto just like invoice
	See 6b8d7bb6d68221f77dabb223de4160fdfb87a6f8

=====

Boxed layout:
	- fix section & note style
	- fix borders in general
	- fix the total table

Background layout:
	- fix section style
	- fix the total table

Clean layout:
	- fix page number vertical align

task-1889346

closes odoo/odoo#27782

col-lg-* -> col-xl-*
col-md-* -> col-lg-*
col-sm-* -> col-md-*
col-xs-* -> col-*

col-lg-offset-* -> offset-xl-*
col-md-offset-* -> offset-lg-*
col-sm-offset-* -> offset-md-*
col-xs-offset-* -> offset-*

col-lg-pull-* -> order-xl-1
col-md-pull-* -> order-lg-1
col-sm-pull-* -> order-md-1
col-xs-pull-* -> order-1

col-lg-push-* -> order-xl-2
col-md-push-* -> order-lg-2
col-sm-push-* -> order-md-2
col-xs-push-* -> order-2

Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.

BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.

The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:

$gray-darker          ->  gray 900 (unused before)
$gray-dark            ->  gray 900
$gray                 ->  gray 700
$gray-light           ->  gray 600
$gray-lighter-darker  ->  gray 400 (the old variable was created by us)
$gray-lighter-dark    ->  gray 300 (the old variable was created by us)
$gray-lighter         ->  gray 200

Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.

The goal is to be able to more easily create section and notes on sale order, invoice, and quote.

================================
Problems of the existing feature
================================

The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.

Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.

==================
New implementation
==================

Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.

We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.

=========
Reasoning
=========

We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.

Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).

The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).

We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.

No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.

===========
Limitations
===========

The current solution has several limitations:

* since the sections don't have business logic, it's not possible to make any reporting based on them

* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display

- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section

===========
Technically
===========

The commit will:

* update the models to add the display_type field (along with related sql constraints to guarantee integrity)

* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button

* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)

!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.

* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)

!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.

Task #53996
PR #25209

*account_payment, l10_in(_sale), sale(_stock), web

With this commit:
The invoice preview in portal (/my/invoices..) is now the HTML version of the
PDF report.
The HTML preview is based on the invoice report to closely match what is
already done in Odoo.

The invoice preview is displayed in an 'iframe', it is mandatory since:
1. Reports are rendered as a separate page as it returns the whole page after
   rendering, which has tag <html>, <head> etc
2. Reports are having their own layouts and their own assets that we we cannot
   load in the page directly or it will break the website layout.
3. We can not use report template with t-call because internally reports are
   using extra params like context_timestamp, company, DateTime, user etc which
   is used in header/footer

--

There will be a chatter (as a modal) to display/see the history of the document

--

For responsive purpose, we use new tables with limited column (Description,
Quantity and Amount) for responsive purpose (small screen).
It also adds some bootstrap classes to reports for responsive purpose.

--

The 'Pay Now' button remains if you already paid with 'wire transfer'.

--

Add margin after the header and before the footer to look like the real printed
document, without alterating the real printed version

Task ID: 39876

Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):

- web._assets_utils: regroups the mixins and functions which *can*
  (and so should) be available in every asset bundle

- web._assets_primary_variables: regroups the variables (or mixins
  used as variables) which *can* (and so should) be available in
  every asset bundle

- web._assets_secondary_variables: same as above but provides an
  environnement where all the 'primary' ones are accessible. This is
  for example useful to handle the community/enterprise split:

  // Community primary variables
  $o-pink-color: pink; // enterprise color
  $o-brand-primary: blue;

  // Enterprise primary variables
  $o-brand-primary: $o-pink-color;

  // Community secondary variables
  $o-my-darker-primary: darken($o-brand-primary, 5%);

  => If there was only one variable template, enterprise edition would
     have been able to define its primary color at the end but the
     darker primary would not have been updated. Using the "!default"
     system and putting enterprise definition above would not have
     solved the problem as the $o-pink-color would not have been
     accessible.

- web._assets_backend_helpers: regroups the variables, mixins and
  functions which *can* (and so should) be available in the backend
  asset bundle only. This is especially (only?) useful for bootstrap
  variables overriddes.

- web._assets_frontend_helpers: regroups the variables, mixins and
  functions which *can* (and so should) be available in the frontend
  asset bundle only. This is especially (only?) useful for bootstrap
  variables overriddes.

Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:

- Find another way: your variable is probably useless, use bootstrap
  variables directly or create a variable that will influence the
  value of bootstrap variables. E.g. instead of declaring:
  `$myvar: $bootstrapvar * 3`
  and using $myvar alone, declare:
  `$myvar: 3` and use `$myvar * $bootstrapvar` where needed.

- Declare a copy of the bootstrap variable and use that one. In that
  case, you should also force-set the real bootstrap one to be sure
  they match (this should be done in appropriate templates mentioned
  above). E.g.
  ```
  $o-boostrapvar: 5;
  ...
  $boostrapvar: $o-bootstrapvar;
  ```

- Set your variable to null and set it to your bootstrap expression
  in the file you will need it (where bootstrap variables are accessible)
  without forgetting to add the !default flag to allow overriddes.
  ```
  $myvar: null;
  ...
  $myvar: $bootstrapvar * 5 !default;
  ```

This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).

Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).

This commit basically changes:
- Variables: @​var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @​mixin mixin-world {}
- Classes used as mixin: .my_class() -> @​extend .my_class
    - Here there were no other solution than to convert the use of
      a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
    - Still need to make sure last variable definition is at the
      right place