Fixes #27471 by just using `tagged()` behind the scenes.

calls to `tagged` were done in the wrong order

closes odoo/odoo#27531

When creating a warehouse with purchase app installed, it will
traceback since the route_warehouse0_buy is referenced in a wrong
module.

closes odoo/odoo#27523

Before this commit, you need to check manually multi website.
And demo data create 2 websites by default, but don't check it.

Multiwebsite cannot work on the saas since the login use a constraint to check that it is an email.

The date picker widget was set to text instead of date.
Then we needed to fix the date validation at form submit.

opw 1890130

closes odoo/odoo#27448

Fix to commit: a1d6064d
Which erroneously put a mass_mailing method in mail,
as mail.mail.statistics is defined in mass_mailing.
Since it does not depend on the records, it been extracted from the
loop.

opw 1890461

closes odoo/odoo#27431

closes odoo/odoo#27505

Do not mix Community and Enterprise color themes. Moreover, increase the
contrast of the control panel for better readability.

closes odoo/odoo#27502

Including demo data

closes odoo/odoo#27504

Several fixes

closes odoo/odoo#27430

Fixes odoo/odoo#27321

Unlike the name suggested, today is expected to be a datetime, not a date object

Fixes odoo/odoo#27445

When auth_password_policy is installed, and a field with
`password="True"` is in a res.config.settings (eg. google calendar is
installed) we could have an error caused by deferred not expected in the
res.config.settings _render.

Since the RPC is only needed when the password_policy has been been
defined, this commit do this removing the error that currently happened.

A customization of res.config.settings adding password_meter would still
break settings (but it is currently not done) and will be solved in a
future fix.
closes #27426

Before the fix, routes using binary_content with access_mode
and access_token didn't work properly since access_token
was compared to the object's access token in all cases.

This commit:

 -prevents the object's access_token check if
access_mode is truthy (since access_mode does its own access_token
check).

 -changes check_access_mode so it now returns a boolean instead of
 a record and is now private.

Closes #27401

- Add a method for generating an image data URI, and expose it in QWeb context

- Fix reports, website templates or mail templates with data hardcoded
  data URIs, to use the helper (Python cases), or the existing
  kanban_image helper (for JS cases)

This will gracefully handle SVG support in addition to classical image
formats.

Closes #26635

Introduce official support for SVG files in the framework, including the
following parts:

1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].

2. Make /web/image controller compatible with SVG

3. Add support for SVG files for company logo, which uses a dedicated
controller.

4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.

5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)

6. Add tests for the SVG upload cases and for the non-admin uploads.

[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_Security

Closes #26635

On an AccessError, the relevant message is passed as the first arg. But
the import error handler would only check for the second arg (if any)
then fallback on error.message, which is missing entirely when the issue
is raised as an except_orm subclass.

These blow up rather dramatically if the corresponding modules are
installed after auth_password_policy.

Auth can now report errors less trivial than "incorrect password", the
wizard should report them instead of just assuming the original
password was not correct.

* generic strenght meter widget which can be included in various
  places
* password field, taking over the isPassword special cases strewn
  throughout the codebase, this should probably become an actual thing
  in core /cc @ged-odoo, the meter is opt-in as most uses of
  `field[@password=True]` are passwords & secrets for third-party
  services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
  view for some reason
* direct implementation for signup pages (create user & reset password)

Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).

Hard-checks password length according to configured rule (default: at
least 8 characters).

Closes #22351

Revision on https://github.com/odoo/odoo/commit/221f469045e32b3bd8bb975dad4467424602cefa

Revision on bus refactoring: https://github.com/odoo/odoo/commit/6448420c5dd160470e465dee7729d19d8d5e7bab

Before this commit, when a user was disconnected for a very long
time, he would receive lots of chat notifications on his next login.

Here is an example of weird behaviour with this issue:

    - User folds and unfolds a chat window 50 times
    - User disconnects for more than 50 seconds
    - User reconnects
    ==> the chat window rapidly folds and unfolds itself 50 times!

This issue comes from the fact that after 50 seconds without any
longpolling, the web client ignores the last tracked notification
and sents the ID `-1` to the server.

The web client always provides a notification ID to the server
on a `longpolling/poll`. Usually, the server returns all
notifications of the user with an ID greater than the provided ID.
There is an exception with ID `0`, in which all notifications since
the last connection of the user are returned.

The cause of the issue is a mismatch of the special notification
ID between the server and the web client. For the web client, the
ID `-1` is used for not tracking any notification, whereas the
server uses the ID `0` for this case. As a result, when the server
receives the value `-1`, it returns all notifications having an ID
greater than `-1`. In other words, it returns all notifications
related to this user, even the ones received long time ago!

This commit fixes the issue by enforcing the special notification ID
`0` on both the webclient and server.

Note that this logic is similar to 11.0:

   - The webclient uses the ID `-1` most of the time to define 'untracked':
   https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L154

   - However, it passes the ID `0` to the server:
   https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L193

This menu mistakenly tells that there is a keyboard
shortcut to navigate in the app menu.

This reverts commit 05971d00.

This menu makes sense in community, therefore we re-enable this
menu.

* mail

Purpose of this merge is to add activity view on main actions of models
inheriting from the activity mixin. Purpose is to help using activities
by having access to the summary activity views.

This merge is related to task ID 1889413 and closes PR #27381.