The project overview is based on the profitability report to get the
amount invoiced and to invoice for service sold on a sale order
linked to a project. This request is wrong as it does not take the
milestone sale line into account. This commit fixes it.

opw-1890106

closes odoo/odoo#27538

Was still pointing to old links

closes odoo/odoo#27443

In 7f29b31c the modifed has been improved but there was a typo if a
column contained an uppercase letter (which happen easily with random
field name in Odoo Studio).

opw-1890248
closes #27546

Allow to generate an access token even on records where the portal user does not
have the write access.
e.g. a customer can access its invoices but is not allowed to modify it

Fixes odoo/odoo#27454

closes odoo/odoo#27455

On the user form view, just after the button box, there might be an
alert component. Since BS4, this alert goes over the floating button
box in community. Before BS4, the button box went over the alert (so it
was functional but still ugly).

This commit adds an extra style for community only: clear the button
box before an alert component.

Closes https://github.com/odoo/odoo/issues/27435

closes odoo/odoo#27566

Targets commit d3530eb0

Purpose
=======
- Improved the layout of the product configurator window in both sale order and web shop
- Added some other minor improvements such as editable="bottom" instead of "top", fields reordering, ...

closes odoo/odoo#27567

When creating a "purchase.requisition" record, the default Operation Type was
always the one defined in the company 1 even if the user was not in the company 1.

opw:1890190

closes odoo/odoo#27520

The `account.financial.report` model has been removed, so these reports
are now deprecated. They will be added back in Enterprise.

opw-1891341

closes odoo/odoo#27559

closes odoo/odoo#27544

The file is not imported by the manifest following the removal of the
reports.

opw-1891341

closes odoo/odoo#27542

Introduced by: https://github.com/odoo/odoo/commit/b0a29c9bad4fb9180ddcdae80529e244c6b61d49

Suppose def1, def2, def3, three deferred.
$.when(def1, def2, def3) is ok
$.when([def1, def2, def3]) is not ok
$.when.apply($, [def1, def2, def3]) is ok

closes odoo/odoo#27513

fixes #27467

closes odoo/odoo#27468

Usecase to reproduce (chrome):
- Create a BoM with float quantity in component
- Print the BoM cost and structure report

When using a type="number" on firefox it is not possible to use a
decimal. However on chrome there is no restriction and a decimal
could be use. It makes senses to be able to work with decimal
(e.g. the UoM is in kg)

It also exists an explicit cast to integer since data are received as
string from the javascript. However since quantity displayed could be
decimal, the cast should be adapted to float.

Closes #27464
Fixes #27437

closes odoo/odoo#27522

Using `request.env` should be reserved for code that lies outside of
model methods (typically: controllers). Model methods have to use the
appropriate `self.env`.

This particular case caused frequent Python-PostgreSQL undetected
deadlocks during installations of website-related modules in 12.0.
One way to reproduce it was to trigger the installation of both
`website` and `website_form` in a single transaction, with neither
pre-installed.

Installing Apps that depend on both would do the job, such as
`website_sale`, provided that GEOIP is available on the system.

In details:
During installation of `website`, new attachments creation would call
get_current_website (see 602807ac and
4f6ec1cd), using the wrong database
cursor: the one from the request instead of the one for the
installation, as provided by `ir.module.module._button_immediate_function`.
This would acquire database locks on `res.country` and `ir.model` in
the wrong transaction, later blocking alterations to `ir.model` in
the installation transaction, e.g. for website_form's
'website_form_access' column.

This combination of events was possible before 12.0, but more difficult
to reproduce as module installations used to happen with a super-user
account, ignoring ACL checks and therefore not locking `ir.model`.

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.