Before this commit, fields were selected on activation (focus) but only
after a setTimeout. This setTimeout is in fact not necessary. Removing
it allows to test the selection in unit tests.

`DebouncedField` and `InputField` classes were not properly factorized,
some of the DebouncedField code had to be part of the `InputField`
class (which is a specialization of `DebouncedField`). Indeed the
`FieldText` class, specialization of `DebouncedField` class, was missing
properties which were part of `InputField` and was duplicating code
which was already defined in `InputField`.

For example, it was not possible to navigate out of text fields in
editable list views with the right/left keys as this was part of the
`InputField` class.

Note: the FieldTextHtmlSimple class was implementing the `commitChanges`
function differently than `DebouncedField` but this was in fact not
necessary. This is why documentation update has also been done for this
by this commit.

Please refer to individual commits for more details. This commit merges
remote-tracking branch 'dev/master-crm-phone-fp-tde'. Closes #16412 .

Rev[0] and [1] introduced a versioning on product's attachments through an
ECO creation or through a stat button on the product form view. These revisions
added some fields on the ir attachment model: a many2one and a boolean field
with a default value, and due to concerns over the migration of databases with a
lot of ir.attachment records (like ours), we adapted the implentation in rev[2][3].

We deemed reasonnable to remove the "active" field, as adding an active field not
in the “base” module of the model could impact other modules that did not took into
consideration this field. Also, this field only had a meaning when mrp_plm is
installed, and ir.attachment is used in various places in contexts across Odoo.

So, rev [2] and [3] changed the implementation of the versioning to only link
ir.attachment to an ECO record, forgetting the functionality of archiving directly
through the product form view stat button (without an ECO).

To introduce back this behavior, we chose to create a model to handle the mrp
attachments (named “mrp.document”) which inheritS ir.attachment. This way, we keep
the behavior of ir.attachment and we do not alter the original table.

This commit moved the priority field already set on ir.attachment to mrp.document
and adds the active field that will be used in mrp_plm to archive/versioning purposes.

linked commit:
[0] https://github.com/odoo/enterprise/commit/99138b6711760a7562cb9559663aef6a4208a48f
[1] https://github.com/odoo/enterprise/commit/4f88eb409776c1c4bc8f8d71d845b913c3604a54

[2] https://github.com/odoo/enterprise/commit/7e1c73cfc84cd23b6ba87dab713c3078de16568d
[3] https://github.com/odoo/enterprise/commit/ee1c4b29b8872dac9c525fcc6acdf80b5ef73131

This rev. fixes 2 issues about many2many fields displayed with
an editable list view, occuring when the user edited some values
in the list.

First, the many2many field was re-rendered each time one of its
sub-widgets triggered a 'field_changed' event, and thus the row
the user was editing was no more in edition and the focused field
was no more focused. This was quite annoying.

Second, when the user saved changes made in the editable list view,
only a command 6 (REPLACE_ALL) was sent, so updates of subrecords
were never saved.

Before this rev., if you opened a form view with, e.g. a float
field, that is unset, and then click on edit, then save, it
actually saved the new value for the float field (being 0),
whereas it shouldn't do any RPC as nothing changed.

This is because the former code couldn't detect if the value "0"
in the input is there because the field is still unset or if the
user simply set it to 0.

PR #16762

This way if phone validation is activated users will have to enter correct
phone numbers. This will greatly help having correct data in customer
tables and improve efficiency of CRM-based flow.

This commit proposes to ease field error management by having a
structured json response having field name as keys and error message
as value. Controllers can return a specific error message for some
fields that is displayed in a popover.

This bridge module adds phone / fax / mobile number validation for lead
and partner models, using the recently-introduced phone validation tool
module.

This is done at onchange level and is therefore not blocking or
computationally heavy. Its main use is to help salesmen correctly
entering or checking phone numbers when using Odoo.

Using phonenumbers library this module adds tools methods as well as a
small mixin for models that want to activate phone number validation
and formatting.

Formatting can be done always using an international format or having
both national and international format. This is configured on the
company.

Note that phonenumbers library is optional. Installing this module without
having the lib installed just skip its use but should not crash.

Will be used in migration scripts to saas~16 to compute this value for all the invoices that have been validated

The process of evaluating a domain is not really difficult, but the hard
part is getting the evaluation context right.  The evaluation context is
supposed to contain informations coming from various sources (active id/ids,
session context, ...).  Before this commit, we just ignored the context coming
from the action.

This could cause many problems. For example, in the Inventory
application: create a picking, add 10 ice cream in initial demand, force
assign, click on scrap.  A form view should be opened (with the context
coming back from the button_scrap method).  In that formview, there is a
many2one Product.  Clicking on it should perform a name_search with a
domain looking like ['id', 'in', [64]].  This domain is the result of
the evaluation of "[('id', 'in', context.get('product_ids', []))]".
Before this commit, product_ids was ignored, so the domain was always
['id', 'in', []].

In this commit, we simply add the element context in the list of sources
when computing the evaluation context (the element context is the
context given to the view, which is the way an action give a context to
a view)

In short, handling context is hard...

If the picking has no carrier set, do not open the put in pack wizard
and keep the behavior of a classic picking. Also, filter the delivery
packages according to the carrier (note: this doesn't work at the moment
because of a bug in the new views, but it'll be fixed very soon, so we
merge anyway).

Also, remove an harmless typo in `manage_package_type` method.

"product packaging" -> "product packages"
"delivery packaging" -> "delivery packages"

Also adapt and simplify stock settings.

Allow other inherited views to still working.

before this fix, a tag is added in the body but never removed

The button allowing the user to translate fields (existing in
previous versions) was not present.

Uncaught TypeError: Cannot read property 'split' of undefined.
Crash when the value of widget 'timezone_mismatch' is false in form view.

When updateStyleInfo is called, the options is not necessarily on
editable area (eg: when update the toolbar for image)

If the option 'event_open_popup' is set to true, then the calendar view will open events (or records) in a FormViewDialog. Otherwise, it will open events in a new form view (with a do_action)

Before this change the t-call can use only receive a literal as parameters:
<t t-call="template.name17" />
This call render the template 'template.name17' with the current context.

Now, we can defined an expression with braces (same syntax that t-attf):
<t t-call="template.name{{ 10 + 7 }}" />
This call render the template 'template.name17' with the current context.

This change allows for greater flexibility for applications using qweb.
(The performance due to this change is unchanged during rendering time.)

These commit are the 3rd part of improvements
of Services flows.

It introduces 2 important parts
- timesheet revenue: how much the timesheet bring back
money.
- timesheet overview: a kind of dashboad to see the financial
state of a project, grouped by employee or billable type

Other improvements are UX, adding missing settings, hide
some technical fields, ... to ease the configuration and
day-to-day usage.

This commits add the timesheet overview on the project
kanban. Instead of redirecting to timesheet list, the user
will see a more detailled view.
The timesheet dashboard shows the amount per billable types,
the numbers of hours provided per employee and per billable
types, ...

This view is integrated with the search view : changing the
filter will shows you the informations for your selection.

The purpose is to give the user a global view of the project
(or other timesheet) financial situation in the same place.

This overview is made to be extended in enterprise to add
a section to compare past (timesheets) and futures (forecasts)
activities.

The purpose is to ease timesheet configuration by
adding missing settings: 'invoicing policy' setting
exists in sale config. This commit duplicate it
into timesheet config.

It also add settings in project, sale and timesheet
to configure more easily the service products (time
and material, and fixed price), by adding filter for
services.

This commit introduces the concept of timesheet
revenue, aka how much the timesheet bring back
money.
If the timesheet is not invoiced yet, the computed
revenue is theorical, based on the billable type
(if your product is Time and Material, or Fixed Price).

The formulae use at the timesheet line creation is

     If product on delivered quantity:
        timesheet hours * (SO Line Price) * (1- discount),
     elif product on ordered quantities & create task:
         min (
            timesheet hours * (SO Line unit price) * (1- discount),
            TOTAL SO - TOTAL INVOICED - sum(timesheet
                revenues with invoice_id=False)
         )
     else: (non billable case)
        0

When the timesheet is invoiced, the revenue is recomputed
based on the prorata of the invoice amount : prorata of
number of hours for 'time and material' product,
prorata of the theorical revenue for 'fixed price' product.

The timesheet revenue is expressed in the currency of the
company (Monetary field, based on the company_currency_id field
of account.analytic.line) to ease reporting.
This feature normally can handle multi currency (different currency
from SO, INV, and analytic account).

Since it is advanced feature, you should be in debug mode to configure them.

Before this rev., the function that parses monetary fields (i.e.
the one that converts the string value of the input into a
numerical value) totally ignored the sign of the value.

Actually, parsing a monetary field is exactly the same as parsing
a float field, so we simply use the same function.

Unit tests are executed after module installation, which is sometimes
challenging when some part of the UI is modified by another module.
In this case, a test in module web/ was implicitely relying on a behaviour
introduced by the module document.
So, the test failed when document was not installed.

Since the installation of ´document´ module changes the toolbar display,
we check in the test if the module is installed to do the correct assertion.

Before this commit, the parameter ´searchview_hidden´ was not used anymore
when it was defined for some views.
After this commit, the search view is hidden when it needs to be, e.g.
the helpdesk dashboard.

Currently using chatter it is possible to create customers directly when
posting a message. Unknown email addresses are proposed to the user that
can create customers directly in the posting process.

However the record is not updated. Several models like lead, issue, ticket
or event track have a customer (partner_id) field that is not updated even
when a customer is created from the chatter. Users have to update records
manually.

This merge automates it by updating the record through a post process
hook on message_post that is used in main customer-based addons. A small
improvement is done in the chatter to reload the record once posting a
message to a new customer.

When a message is posted through the chatter and creates a new partner
the attendee or track is now updated so that the partner field is correctly
set to the newly-created partner.

Chatter on attendee or track now uses the reload option so that the view is
reloaded after posting a message. The user therefore sees that the record
has been updated accordingly.

When a message is posted through the chatter and creates a new partner
the applicant is now updated so that the partner field is correctly set
to the newly-created partner.

Chatter on applicant now uses the reload option so that the view is
reloaded after posting a message. The user therefore sees that the record
has been updated accordingly.

When a message is posted through the chatter and creates a new partner
the issue is now updated so that the partner field is correctly set to
the newly-created partner.

Chatter on issue now uses the reload option so that the view is reloaded
after posting a message. The user therefore sees that the record has been
updated accordingly.

When a message is posted through the chatter and creates a new partner
the lead / opportunity is now updated so that the partner field is
correctly set to the newly-created partner.

Chatter on lead / opportunity now uses the reload option so that the
view is reloaded after posting a message. The user therefore sees that
the record has been updated accordingly.

Purpose is to be able to reload the view after posting a
message using the chatter. Reason behind that move is that
records can be updated after processing message_post and
this is the easiest solution to enable the reload feature
without having an event-based chatter.