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.

Models inheriting from mail.thread can override this method and hook
on post message_post event and perform some action depending on the
business flow.

Future commits will use that hook to update the record after posting
a message, like updating the customer.

Somewhere in the new views refactoring, between file splitting and rpc
engine quadruple refactoring, a deferred was lost. Due to this chatter
does not have correct information about message recipients.

This commit fixes it by putting the deferred back.

There is currently no 'followed task' filter. Making custom filter does
not work as it erases existing search. When working in some projet context
you do not want to loose your existing search criterions. We therefore
choose to add a new 'my followed task' filter.

We could have made ir.filters not exclusive aka add them to existing
search criterions but "some people" did not want.

Last but not least, we add this filter because FGI requested it.
It seems sufficien to me.

The editable list view may be really new, but it still suffers from a
performance issue.  The problem is that we need to evaluate modifiers
for a (sometimes) large number of fields: a list view with 80 rows and 7
columns has 560 field values.  This is not so large, but each of these
evaluation is still costly.

In particular, it needs to compute the evaluation context.  However, the
evaluation context is the same between all fields of the same record, so
in that case, the web framework does way too much work (with 7 columns,
it is 7 times too much).

This commit does not totally fix the issue, but it helps quite a lot.
What we do is just memoize the evalcontext computation. This means that
it will be evaluated only the first time it is needed, then will be kept
in memory.

Note that this is a fix, not an imp. The list view should be fast...

When a record is added in an x2many field with an onchange, the
onchange is only triggered once the new record is valid (i.e. when
all its required fields have a correct value).

However, there was an issue in the code checking the validity of
a record, as it checked, for each required field, that its value
wasn't falsy (!value). This is incorrect for several type of
fields:
 - numerical: a value of 0 is correct
 - boolean: should be always considered as correct
 - x2m: their value is a dataPoint, so it is never falsy, what
   should be check is the number of records inside the dataPoint.

This was an issue for example in the sale.order form view, as the
onchange wasn't triggered when an order line was added (with a set
product), so the total amount wasn't updated correctly.

Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).

This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
  in x_layout.less and x.less was a mistake. Many rules can be
  considered to be layout and not layout at the same time, developers
  always have to switch from one file part to the other, many CSS
  selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
  fields.less file. As before, the fields_extra.less will contain the
  rules specific to community so that the enterprise repo can override
  those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
  many classes can now be applied outside of form view. These classes
  should not be used in templates anyway.

The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).

Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.

The editable list view should also completely stop flickering on chrome
and firefox.

The commit also removes the orange outline on list view dirty cells.

The commit also removes deprecated static xml, LESS and other code.

Notice there are still styles to restore/fix and LESS to improve.

One could set the attribute `default_order` in the view arch
(like 'name,id desc'). The records should then be sorted accordingly.

This feature was not implemented in the new views.

This attribute should work on both basic views and embedded views (x2many).
The former uses the `sort` argument in `search_read` while the latter is
sorted client-side.

There is however a potential issue with the latter: as the order is done
client-side with records received by the server, if there are more records
than the limit, the server will send records without any order. The client
side order will thus be done on a fraction of the records.

The method `load_more` has been wrongly removed from the Kanban model.

This attribute is used to determine one can create a new column in
the kanban view.

Before this commit, it was always true and not specified in the
controller `activeActions` (which was causing a bug where the
no content helper was displayed instead of the column quick create).

The controller was also always initiated with false so the column was
only available after an update.

The third argument of kanban_image should be the id of the record and not the
image `raw_value`.

In this case, we want to display the image field of the current model.

The commit e07f27d4 has wrongly changed the fallback for one2many raw_value from
an empty array to `false`. This modification brokes a lot of templates where we
assume that the value is always an array.

This commit restores the previous behavior with the fallback on [].

The template `wizard_checkout` uses the `website_sale_order` to render the checkout process pages

But this values isn't passed to the template on these staps:
- /shop/checkout/
- /shop/address/

Purpose
=======

Address management is not clear. If you use the eCommerce, you can set 2 different addresses (billing / shipping) in the checkout process while the related access right group is not activated (group_sale_delivery_address). So you don't see such dates in the backend, which leads to potential conflicts with customer (if the delivery address is different).

Functional spec
===============

- Hide shipping stuff in checkout if option is not activated:
- When eCommerce is installed, group_sale_delivery_address should be activated automatically.
- If you uncheck it from user access (already it is disable in sale settings) , it has to disappear in both the bakend AND the frontend.

With this commit, we try to improve the way navigation is done in the
list view.  In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).

Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).

Graph tooltips (found in accounts and sale/crm's dahsboards) are now
rendering a custom template in order to display more relevant and
coherent information about the graph.

"No, no, I am not the brain specialist. No, no, I am not! Yes. Yes I am."

In the accounting graphs, the graph's color and tooltip didn't match
for linecharts. This commit fixes that.

When we unselect a line in a one2many list, we ask for all fields to
commit their changes (because many fields are debounced, so we may not
know their current last value).  This is good, except that it could
trigger an extra field change event, which may in turn trigger a second
onchange.

We solve this issue by improving the _setValue method and delegating the
comparison to a new _isSameValue method.

It is particularly relevant for field types such as integer, which are not
stored as a string.

Invoices were marked as paid as soon as validated, if the income/expenses accounts was reconciliable (for some reason?)

- task https://www.odoo.com/web#id=32324&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
- PR #16311

When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").

Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c42).

note: master equivalent of 8f1cc2fa (which is for 10.0 up to saas-15)

opw-705329
closes #16775

This widget is supposed to be used in list views only (it allows
to re-order the rows by drag-and-dropping them).

Since the new views, the field widgets are shared between all
views, whereas before, each view had its own list of widgets
(and the handle widget was a list view widget).

So if one specifies widget='handle' in a form view, the handle
widget will now be instantiated, whereas before it was ignored.

This rev. fixes two templates making use of the handle widget in
form views.

Suppose that there is a many2many (list) field in a form view,
and there is a many2many (e.g. many2many_tags) field inside the
list.

In edit mode, if the user adds a record in the relation, this
record and its relational data should be fetched.

Before this rev., the relational data wasn't fetched, so the
many2many_tags couldn't be displayed correctly.

* added some accounts, cash based taxes, DOM-TOM country group...
* improved sale/purchase journal creation for french companies by making sure they have a dedicated sequence for refunds

This is probably needed by all countries that use caseh basis taxes, and will save them the journal creation + save of the settings.

The constraint is `UNIQUE(model, name)` on `ir.model.fields`.

Problem: the update of custom models/fields is not fully transactional, and may
potentially lead to an inconsistent database.  An other problem is creating two
custom fields by writing on a model: if the second one fails, the first one has
been committed without notice.  Retrying the request will give an unexpected
error (duplicate field name).

Solution: never commit in the middle of a request.  If the changes have an
impact on the registry, then mark it as invalid (with a new flag), and signal
registry invalidation after everything has been committed.  If the request
fails, reset the registry.  Both registry and cache invalidation are handled
the same way.

Delegate to models `ir.model` and `ir.model.fields`, so that this functionality
can be extended easily.