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

This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
  _("Foo %s", bar)

to progressively migrate the code to the new syntax.

A few calls were not technically incorrect but still detected by the
linter.

  _("Foo" +
    "Bar")

has been converted to

  _("Foo"
    "Bar")

as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).

closes odoo/odoo#53683

Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

When company layout is changed, we do not update the company styles for
report: thus we still have the old style for other layout that will not
change anything (besides font).

opw-2269849
closes #53706

closes odoo/odoo#53720

X-original-commit: 8897701b1754b40d8a83c5681907c38fb205657f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

The counters for categories were not updated when filter values were
selected. This commit fixes that situation.
This might impact the global performances of the search panel but
there is still room for improvement. Actually, it could be
possible to reload categories and filters less often by carefully
track the internal changes and the categories/filters attributes
(enable counters, expand,...).

closes odoo/odoo#49307

Related: odoo/enterprise#9795
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

In the search panel, the domain used to compute the field image values
(when the attribute expand is false) was the same as the domain used
to compute counters (if enabled). The idea was that a value bringing an
empty domain is totally useless and should not displayed.
That being true, it turns out that if one does not allow them and
several fields are used, selecting a value in the search panel will very
often totally transform the search panel. From a UI perspective,
this turns out to be bad: the search panel 'moves'.
Let us give an example:
Let us start from a search panel that looks like to:

first_field
    A  1
    B  3
second_field
    C  1
    D  2 <--- mouse above D
    E  1

with first_field and second_field both with expand="0" and
enable_counters="1". Let us also assume that no record in the global
domain has both first_field=A and second_field=D.
Click on D would make the search panel look like to something like

first_field
    B  1
second_field
    C  1
    D  2
    E  1 <--- mouse here

(the selection of D does not impact the values for the second_field but
does for the other first_field values).

This has led us to use basically only the domain comming from
outside of the search panel to compute field image values.

This means that we might now have value with zero count even if expand
is false. In the above situation, a click on D would give us

first_field
    A
    B  1
second_field
    C  1
    D  2 <--- mouse still above D
    E  1

Task ID: 2154749

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.

Task ID: 2154749

The commit introduces two new attributes for search panel fields:

    - hierarchize: boolean attribute (default True) available for
      many2one fields with select="one". It allows to choose whether
      to hierarchize the field values using the _parent_name (if set)
      on the field comodel.
      Note that a sanitization of the parent hierarchy takes place.
      Basically, it ensures that parent chains are
      completely in the domain (on comodel) accessible by the user.
      See _search_panel_sanitized_parent_hierarchy documentation for
      more information.

    - expand: boolean attribute (default False) available for many2one
      and many2many fields. If set to true, all field values are fetched
      and displayed in the search panel. If set to false, only the
      values that have at least one corresponding value in the field
      model (and in some domain) are fetched.
      An exception in the case of an hierarchized field
      (hierarchize=True and _parent_name set): more/less values can be
      displayed in order to have a good representation of the parent
      hierarchy. That means we complete and sanitize the set of initial
      field image values.

Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.

Task ID: 2154749

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

In the search panel, the attribute disable_counters with default False
has been changed to enable_counters with default False.

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.

This commit introduces several changes in the search panel with
respect to record counts:

    - the record counts are now also available for
      the fields with select="one" attribute
      (if not disabled explicitely).
    - the record counts are better computed using the idea that
      selected values within a group should not impact the counts
      for the group values but only the counts for the other
      group values.

On the way we have changed two keys in the values returned
by the server:
    - 'count' becomes '__count'.
      It has been done to avoid a possible clash in case a model would
      have a field named 'count' and that the field values would be
      wanted for some reason.
    - 'name' (multi case) becomes 'display_name'.
      It has been done in order to make the select one and multi cases
      more similar and factorize some code.

TASK-ID: 2166814

Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>