* 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>

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>

When exporting a grouped list view with some nested groups, the aggregate value
of parent groups are not correct. It always sums aggregated values of children
whether the group operator is 'sum' or not (could be 'max', 'avg', ...).

This behavior is wrong and can even lead to a crash if the aggregated field is a
date field (e.g. with group_operator='max'). (Try two sum two dates...)

The quick fix 85cf47f was merged just before OXP to avoid any crash. This fix
limited the support of aggregates to only int and float fields.
This commit remove this limitation.

This commit correclty implements the aggregation for parent group for all
field types and all group_operator.

This commit also improves the export feature tests.

X-original-commit: 5e7e4fa98698967e3c4fd0903f4aa8e91981a6cd

PURPOSE
=======

Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.

SPECIFICATION
=============

When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
  same info (label, field aggregates) as it has in the listview.

New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
  according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
    - select all records
    - hit 'action' then 'export'
    - hit 'export'

Define a boolean attribute on <tree> to specify whether or not the export shortcut should be displayed

Task 2072910

This reverts commit ac00548b28c0c384b5b1423f65405e4918101872.

Purpose
=======

Have a quick export feature.

The current export wizard is quite complex.
We want to be able to quickly export a tree view,
with the group by correctly represented, depending on the fields
visible in the list view.

Specification
=============

Add an "EXPORT (XLS)" button in the list view (a little download icon)
- export only columns visible in list view
- export all the records
- while respecting the group by

This should be a generic feature but should be applied to all
the account.move.lines list views.
account.view_move_line_tree_grouped_sales_purchases
account.view_move_line_tree_grouped_bank_cash
account.view_move_line_tree_grouped_misc

Task 2031835

closes odoo/odoo#36943

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

In 3d2ca8104e4 some change were introduced to the graph view.

But part of it had no sense when displaying data over 2 group by.

eg. if the first level has 2 groups (2018, 2019) and each second level 2
    groups (Done,Cancelled), we could have:
     2018/Done: 0
     2018/Cancelled: 5
     2019/Done: 8
     2019/Cancelled: 9
    this gives us two main groups [2018: 5] / [2019: 17], the code
    remove the 2018 because [2018/Done] is 0 so we have something odd
    with columns not in order, and in stacked bar chart some part of
    a bar at the wrong offset

opw-1932517
closes #30529

This commit adds a new js test in web that enters each app and click on
each view switcher, each menu and each search filter.

This test is tagged '-standard' and 'click_all' as it could last a long
time, that way it's not executed by default.

It could also be started from the browser console with
'clickEverywhere();'.

* LDAP import: python-ldap is not python3-compatible, pyldap is

  Warning: only supported from debian Stretch (current testing)?
  https://packages.debian.org/search?searchon=names&keywords=pyldap

* implicitly relative imports
* imports of moved or removed stdlib modules

issue #8530