When converting UoM, the conversion can fail if the source and destination
uoM are not in the same category. By default, and error is raised, but using
a context key, we can receive the initial quantity.
To avoid the context key (which is not used anymore), we prefer use a dedicated
parameter to be more explicit.

Issue: when displaying the shortcuts with ALT key, when a dialog is open
the shortcuts are displayed in absolute position above the gray overlay
of the dialog, so it is possible to click on the buttons of the
shortcuts.
This fix will remove this possibility.

Reproduce the issue:
- open the manual reconciliation (it is a client action)
- add a reconciliation (using the + sign)
- expand it (using the > sign)
- put the focus on the first field and hit TAB
--> you would expect that the focus moves to the second field
--> what happens is: the focus stays on the first field

Before this fix, when in a client action (or any place that contains
fields) that contains fields, the keyboard navigation did not occur
correctly because the default behavior of the TAB key was prevented.

After this fix, if the navigation_move event was not stopped, we allow
the default behavior of the TAB key.

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.

Recently, rev. 5b3cb812 added a new custom event ('update_filters')
handler to the ActionManager, and rev. 69c9500e added an option
('keepSearchView') to doAction (which can be called by triggering
up event 'do_action').

Both events ('update_filters' and 'do_action') can be triggered by
controllers, and when those controllers were in the dashboard, a
crash occured when they triggered those events. In particular, they
are triggered by the new 'web_dashboard' view, respectively when
clicking on an aggregate and when clicking on the subview button to
open it full screen.

The crashes occurred because the events weren't intercepted by the
dashboard, so they bubbled up to the ActionManager which couldn't
handle the requests properly as it wasn't aware of those sub
controllers.

As there is no search view in the dashboard, the 'update_filters'
event simply needs to be stopped (we can't handle such a request
in the dashboard), and for the 'do_action' event, the
'keepSearchView' option must be forced to false as there is no
search view to keep (we thus force the ActionManager to create a
new one).

Instead, create a new BoardView (in JS only) instead, referenced by
specifying js_class="board" on the fly on the root node of the
arch of the board view.

This ensures that the dashboard addon doesn't impact the FormView,
and this is necessary to ensure that the next commit doesn't break
anything.

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!

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

Before this fix, when navigating with LEFT and RIGHT keys on a grouped
kanban view, if there were empty columns in the direction of the
navigation, the focus did not change to the next column.
After this fix, the navigation left and right ignore empty columns and
jump to the first non-empty column.

Before this fix, list view and kanban views are scrolling every time
the user uses the up and down keys.
After this fix the list and kanban views will only scroll when the user
arrives at the boder of the window

We want to retrieve easily the non billable task from
project plan. This commit makes the "Non billable" label
clickable, in the "Hours" sections, and trigger the actions
to display non billable tasks of projects matching the search
of the overview.

Task #1834454

You can sell services in days, and your timesheet will
be expressed in hours. But on project plan, UoM conversion
is not supported and in some calculation, we are mixing
appels and oranges.
This commit fixes this issue.

No mention of the group_operator attribute was made in the dashboard view documentation.
This fixes remedies this situation and slightly ameliorates the previous documentation.

Commit 07ae0ccc set activities as not followed by default on records.
However this has an impact on performance test that should not happen.
Indeed performance tests should be based on technical decisions, not business
decisions. We therefore set activities as followed by default in some advanced
performance tests to always have results that can be compared.

'allow_timesheet' is true by default, but when installing hr_timesheet for already
created project, populating the column does not use write method, and so, no
analytic account is generated for existing project.
It is required to use the same mecanism as in resource (calendar generation),
and to do so, rewrite part of create/write method of project.project.

This commit also add an onchange, to maintaint consistency about having
no analytic account does not allow timesheet on project.

This fix allows the documentation to be built again.

The keyboard shortcut branch recently added a method
updateModifiersValue on the widget class, which is used to make a widget
aware of its modifier status (in particular, if it is required).  This
is necessary for the proper navigation behaviour on field widgets, but
should not be on the widget class.

The proper fix is, in my opinion, to introduce a AbstractViewWidget
class which would be used for AbstractField and all custom widgets in
views.

Meanwhile, this commit simply protects the call to that method. This is a
refactoring, but can be merged in saas-11.3.

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