* IMPACTED VERSIONS

  12.0+

* HOW TO REPRODUCE

locale :  Locale is en_US (or other SUNDAY based)
view:     CRM - My Pipeline - Kanban view
groupBy:  date_deadline:week (Expected closing)
records:  one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
          one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark:   don't keep any other record in MAY for better visibility

* PROBLEM

The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02

* CAUSE

1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
  the start of a WEEK is always MONDAY. There is no argument to change this.

2. _read_group_format_result
  https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219

  - Computes a label for a group of records.
  - Follows the locale for the label of the week, based on a date which is
    always a MONDAY because of `date_trunc`.

3. read_progress_bar
  https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175

  - Associates a group label to a record.
  - Follows the locale for the label of the week, based on the date of a record
    which can be any day of the week. If the record is related to a SUNDAY and
    SUNDAY is the first day of the week, it would have been in a group with a
    different label in (2.) than in (3.) prior to this change.

* FIX

In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).

* TEST

Added a test for this problem case

TASK-ID : 2517848

closes odoo/odoo#70453

X-original-commit: c08f6e3e9a084944ea711d33b2421f845c560d3f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Disabled in odoo/odoo@b992619840a70c600c50fac0383ad9396351af75
by mistake.

Also, restore the "failfast" for the QUnit tests (disabled in the same
commit...).

The unit test in `test_base_document_layout` does not pass with
version 7.0.0 of PIL, which is loaded by default on Ubuntu 20.04.
The reason is that the color obtained from the image is slightly
different.  This fix slightly relaxes the test (in fact we don't care
about the exact color obtained in this test, we just want to make sure
that it doesn't crash)

opw-2342394 (original ticket)

closes odoo/odoo#59912

X-original-commit: 3028c814d62309bfa2a55f9aaa775738263d8326
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>

Behavior before the fix:

Uploading a grayscale image with transparency in the company logo field
of the document layout causes a crash:

```
  File "/data/build/odoo/addons/web/models/base_document_layout.py", line 89, in _compute_logo_colors
    wizard.logo_primary_color, wizard.logo_secondary_color = wizard_for_image._parse_logo_colors()
  File "/data/build/odoo/addons/web/models/base_document_layout.py", line 191, in _parse_logo_colors
    color[1][2] > white_threshold) and color[1][3] > 0:
Exception

...
IndexError: tuple index out of range
```

To reproduce, use the `logo_ci.png` image included in the unit test
data and load it in the document layout (under General Settings).

The system does not detect that the image does not have color
information and attempts to read the R,G,B values (but the image only
has 2 values per pixel: the grayscale value and the alpha)

Versions affected: 13, 14

Behavior after the fix:

The image is loaded correctly (arguably, there is not a lot of interest
in detecting the primary color of a grayscale image, but the script
still returns a (gray) value which is preferrable to a traceback)

opw-2352394

closes odoo/odoo#59381

X-original-commit: 9efe5608aa4fb4f66475d3cb3e15ea332a3ded38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Linearity is not always perfect, managing more template will sometimes lead to slighlty
more than a linear ratio randomly. The maximum observed ratio was 10.9.
12 seems a good value to catch non linear treatment while avoiding false positive.

closes odoo/odoo#59021

X-original-commit: 62610f7851f0994fc0864f2b95851ce8b5984ce7
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.

Show a toast notification indicating the success of the action.

Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.

Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.

The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.

The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.

The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.

Refactor all this from base to web.

Task ID 2304177

closes odoo/odoo#56415

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Assets bundle names have been changed in #48676 but QUnit.only uses check was
still using old names. This commit makes that check use the new names.

task-2274185

closes odoo/odoo#52687

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Before this commit and following the refactoring of the home menu and the control
panel to the Owl framework, some of the helpers of the 'clickEverywhere' test have
not been properly updated to the new classes/behaviours.

Now the selectors target the right elements and some actions that were previously
synchronous are now properly awaited (home menu toggling, filter menu interactions,
etc.).

Also slightly changed the behaviour of the clickAll functions:
- requesting a click on a null element will make the test crash (added some conditions
  to avoid this in a standard flow).
- any error crashing the test at a deeper level will be displayed in the console
- an animation frame is awaited after clicking on an element. This is to comply
  with the Owl rendering system.

closes odoo/odoo#47762

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:

The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.

This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries

Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.

This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)

A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.

closes odoo/odoo#47283

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>