This was introduced as a fix for grouped list views' headers while we
should have added the 'o_list_number' class instead... which is the
case now. So the oe_number rule became useless.

See https://github.com/odoo/enterprise/commit/a2ce226a2a085b26174cdfd32922517dff39658c
See https://github.com/odoo/odoo/commit/5d13a2f431e1c96e075b04d0eb07d98b912a6547
See https://github.com/odoo/odoo/pull/23966

Here is a scenario that could happen before this commit:
1. web client is started
2. it binds a callback on hashchange
3. it performs some async work (read initial action for user)
4. the user (or more likely, a tour) changes the url
5. the hashchange handler is called, and it starts a new action
6. the async work for the web client is over, it then executes the
default action and/or clicks on the first menu
7. we are now in the default action state, instead of the desired action
state (the one from the new url)

With this fix, we simply do nothing when there was an hashchange before
the initial action was done.

Closes #24237

[IMP] project: automated mail, improve subject (as it's sent 3 days later, 'Odoo is up and running' feels wrong

In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.

The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed.  With the
extra size class, this number was undefined, which caused an issue.

The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process.  For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.

When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.

Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it.  As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.

Purpose
=======

The method compute is annoying for the following reasons:
- 'compute' is difficult to grep
- Developers don't understand that they can specify the company and
  the date on which we want to convert the amount. This is quite
  error prone because if these parameters aren't specified, they are
  set by default to the company of the current user and the current
  date (today).
- Passing parameters is the context is not a correct way to call a method.
  Furthermore, using with_context is not really good for the performance too,
  as the record as to be rebrowsed, the computed fields have to be
  re-evaluated

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

- Introduce a new method '_convert'. This method takes 2 more
  parameters: 'company' and 'date'.
- Deprecate 'compute' and '_compute'. Log a warning to notify that we
  should use '_convert'.

Was PR #23607. Courtesy of Alexis de Lattre (Akretion France)

Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community.  The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.

What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
  action
- the tour is broken.

The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive.  This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.

The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous

In Less, the size_class XL is now defined and can be used in media-queries.
It is also added in JS for the sake of consistency.

This new size is needed for a fix in enterprise.

Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.

For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.

With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.

It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.

Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature.  This allows us to increase the global
timeout for the js test suite without fear!

Note: original work of @dbh-odoo was to have + and - buttons on the
editor overlay but specs changed to use a standard dropdown (the work
of @dbh-odoo was thus adapted for this).

See task-46094
Closes https://github.com/odoo/odoo/pull/22197

It doesn't have res_id then there is no meaning to select that record and
perform operation on it.

Related to issue #1776814

Had no effect as no inverse method is set

Reported at #24152

As Agrolait is in Belgium, use a valid IBAN to be usable in iban validation

Closes #24152

Was PR #24172. Courtesy of Florent de Labarre

We now prevent users from defining group taxes using the current tax as
its children taxes.

Fixes #19997
task# 1819407

Currently, when the button "More" is opened, the HTML elements of their
items are located before the button, instead of being after. That means,
when navigating using the keyboard, if the button is opened ant `<tab>`
is pressed, the focus will not go to the menu items.

This change causes the HTML elements of the menu items to be moved, from
before to after the button "More".

PR #23865

With this commit, the menu item for editing a view in debug mode has been
changed.

Instead of "Edit List View", it is now "Edit View: List".

That way, the code is shorter, generic, and translatable.

Exception to above changes: search view, which is unchanged
(it remains "Edit Searchview")

This commit add the reference documentation for the new dashboard view.
In an ideal world, this should be done in the enterprise repository, but
our documentation system is not extensible that way.

With this commit, the fields many2one are not always measures in pivot
and graph views. By default, they are *not* measures.

In order to have them as measures, we should pass `additionalMeasures`
as a param to any of the views, which contains a list of fields to consider
as measures.

example:

    Suppose a model with the following fields:

        - `product_id` (many2one)
        - `categ_id` (many2one)
        - `sold` (float)

    By default, only the field `sold` is a measure
    in a graph or pivot view.

    In order to pass `product_id` as a measure of
    a graph view, you should instantiate this view
    as follow:

``
    var viewInfo = /* ... */;
    var params = {
        additionalMeasures = ['product_id'],
    };
    var graph = new GraphView(viewInfo, params);
``

An exception to the rule above is when the many2one field is of type `measure`
in the arch: this field is set as the default measure of the view, therefore
it is implicitly added as an additional measure.

We recently added the possibility of aggregating the graph view on a
many2one field (with count distinct operator).  This is useful, but then
a rare situation could happen: the view could be grouped by the same
field.

In that case, there is a name clash in the read_group, and the result
will be that the [id, nameget] of a m2o field will be used as an
aggregate.

The readgroup method should be improved (its API is a mess), but
meanwhile, we have a solution for this issue: if we group by a m2o, then
it is guaranteed that each group has an aggregate value of 1 for the
same field.

With this commit, we add the possibility of using many2ones as measure.
The way a many2one is aggregated is by using the count distinct
operator.

Some care had to be done to gracefully support the situation when a
pivot view is grouped by a m2o field F, and the same field F is used as
a measure.

Currently a lot of people are automatically added as followers of expense
reports. However most of them (managers notably) can choose what to follow
using subtypes on the department. We should avoid adding too much people
as following records should stay an active choice made by users.

From now on auto subscription works on
 * employee of the expense report, if he has an user;
 * responsible of the expense report, that is the expense manager or the
   manager of the employee;

Expense report creator is not follower of the expense report by default
anymore, as previous values should be sufficient to ensure people having
to work on the expense report are already followers.

This commit is related to task ID 1819541.

User notifications are defined as
 * notes;
 * pushed to user Inbox or email through classic notification process;
 * not linked to any document, meaning model and res_id are void;

When pushed in user's Inbox they are currently displayed with a gray
background like all notes. However UX experts think it should use a white
background to be easier to spot in chatter. This commit makes it work.
From now on discussion and user's notifications are displayed using a white
background. This commit is related to task ID 1829872.

Activities are quite personal and linked to daily jobs of people using it.
Being notified of all activities is therefore not considered as default
behavior and should be a choice done by users. Subtype linked to logged
activities is now not followed by default anymore. It is still configurable
through subscription widget or parent subscription (project/task for example).

This commit is linked to task ID 1824141.

Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.

In saas 11.2 a _message_log shortcut has been added to log notes and in saas
11.3 a message_notify has been added to notify peopel of a custom content.
Those methods should have the same behavior when author has no email.
Currently there is a crash when trying to encode its email. After this commit
an exceptions is raised like classic post.

This commit is a manual forward-port of 3a978cc64e6b1d8aca7cfd5d4e319bcb302dd262 as well as an improvement
to fix the newly-introduced message_notify method.

Those are notoriously prone to have a one query more-or-less behavior.

This merge goes through various cache invalidation done in mail application
in order to effectively limit it to records and/or fields to invalidate.
Purpose is to avoid having too much cache invalidation that causes to
fetch data again, therefore adding computation and queries to various mail
features. See sub commits for more details about the changes.

All performance tests are improved of a few queries as there is less data
to fetch again from database. On overall community runbot this leads to a
gain of about 16K queries when installing all 205 modules. This merge is
related to task ID 1834147. Closes #24061 .

This commit proposes to limit cache invalidation at some cases that will
trigger some behavior change when dealing with mail messages :

 * creating messages linked to a document;
 * update model or res_id of a message;
 * updating notifications, as notified people could change some computed
   fields on the record;

This commit also invalidates only mail-related fields as updating messages
should not invalidate other things than some computed fields linked to
mail.

Cache invalidation when subscribing people has been added at e6f038a8.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.

However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.

Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.

Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c21092.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.

This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.

A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.

When notifying partners or channels of a message, a cache invalidation is
currently done if the message has a parent. This invalidation has been done
when migrating the mail module at the new API at 4b122ad4.

In that time notifying people of a message lead to the creation of
notifications of the parent message, if any. It was due to the chatter
being threaded and therefore displaying message with their header message.
Adding notifications for the parent was necessary to avoid access rights
issues  when fetching parent message data. Indeed as being notified is one
of the rule to see a message record adding notifications was done. A cache
invalidation has therefore been added to clean the message cache and ensure
everything was fine.

Commit 88b8cd05 changed the way notifications are modeled in Odoo.
Notification on parent message was removed and access rights changed. Threaded
mode for Chatter has also been removed. However cache invalidation has been
kept probably by fear of removing it.

It does not seem to have any viable reason to invalidate cache when a message
has a parent. Posting a message does not push other messages in users's Inbox
meaning there should not be any issue with the cache preventing to see
messages.

Removing this cache invalidation allow to gain queries in performance tests.
It has an impact on each process involving message creation which is quite
common in Odoo.

repro : open any editor (like tasks), empty its content and hit SHIFT+TAB
before this fix: you get a traceback
after this fix: you don't get a traceback

    1. Added the ability to navigate within the kanban view using UP,
        DOWN, LEFT and RIGHT keys.
    2. By defaults, the focus should be set on the search input field.
    3. From the search input field, using the DOWN key, the focus goes
        to the first card of the kanban
    4. From the search input field, using TAB key, the focus goes to the
        create button
    5. From the create/import buttons, using TAB or DOWN key goes to the
        first card of the kanban, then UP and DOWN keys moves the focus
        from card to card in the same column or if it is not a grouped
        view from left to right.
    6. In grouped view, LEFT and RIGHT keys moves the focus to the next
        column
    7. When on a card, hitting ENTER opens the view of that card.

Not included in this commit
    1. Memorize the position on the kanban when opening an card, than restoring
        when going back to that kanban