`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.

closes odoo/odoo#70000

Related: odoo/enterprise#18001
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Steps:
- Go to "Website" > "Go to Website"
- Click Edit in the top right corner
- Click Options
- Select "Add a Google Font" in the Font Family field
- Insert an erroneous Google Font link (e.g. https://fonts.google.com/specimen/Robotoj )
- Save & Reload
- Click Edit again

Bug:
The Edit button is not responding anymore

Explanation:
We try to `@import` the link in multiple files.
For example, here: https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/website/static/src/scss/website.scss#L10
An erroneous font family results in an error 400 from the Google Fonts
server. This prevents parts of the JS to load and makes it impossible to
enter the edition mode.

`EditPageMenu` handles the behavior when clicking on the Edit button.
This menu depends on `website.compiled_assets_wysiwyg` as seen here:
https://github.com/odoo/odoo/blob/b02a99bec709b5a6dc4dabb6cb81435dadc24e7e/addons/website/static/src/js/menu/edit.js#L10-L14
Since there is an error generating the file, the Promise fails but the
error is not handled:
https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/web/static/src/js/core/ajax.js#L164-L168
This commit prevents CSS loading errors from silently failing. The crash
screen will only show up if the user is logged in and has edition
rights.

This commit also prevents the user from posting the form if the font is
not accessible. At the moment, querying an unknown Google font from a
script will result in a CORS error. A valid one will pass just fine. In
case Google changes the behavior of these queries and allows the 400 to
be sent, the fix also checks if the query returned an `ok` status code.

opw:2439073

closes odoo/odoo#64695

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

render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id

Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.

If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.

This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.

Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.

Part of https://github.com/odoo/odoo/pull/48981

closes odoo/odoo#48981

closes odoo/odoo#49398

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

The caching system which was implemented was not working if the
same asset was asked twice "at the same time" = "if the second demand
occured while the first demand's RPC loading was taking place".

Part of https://github.com/odoo/odoo/pull/48981

X-original-commit: ba0ac348a3700331cec6955625ca2b6c72600ced

*: web

Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.

This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.

Part of https://github.com/odoo/odoo/pull/44596

closes odoo/odoo#44596

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

Several XHR error handlers expect a data.arguments member which holds
the args tuple from the Python exception.

Some have alternate codepaths for "xhr errors" but several
don't (e.g. addons/payment/static/src/js/payment_form.js:142,
addons/web/static/src/js/services/crash_manager.js:229,
addons/website/static/src/js/content/website_root.js:167) and will
thus blow up on synthetic client-side xhr errors.

Modify the synthetic errors so they provide that member as an array.

closes odoo/odoo#34850

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#34820

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>