Complement to https://github.com/odoo/odoo/commit/025fa4791c966cc35ad81f5664f25c8bd0502fb5
See #9731

Add a method to format a date in a given language. This appears to be
useful since formatting is not always done by QWeb, but also:
- in mail templates
- in formatted strings (error messages, pre-filled text fields)

PURPOSE
=======

Clarify name of the buttons for the users. Two buttons doing the same thing shouldn't be named differently.

SPEC
====

Rename the button "reserve" to "check availability" to make it consistent with the button on MO.

Example: 'Subtotal' instead of 'Total without taxes' or 'Price'

Purpose
=======
When there are lots of shared filters then its difficult to differentiate personal and shared filters

Specification
==========
- Show all personal filters first as user will prefer his own filters to come first in list
- Show all shared filters after personal filter in list
- Add separator line between personal and shared filter

Purpose
=======

The default group-by in the inventory valuation prevent from doing an easy selection and exporting the data.

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

The group-by in Inventory Valuation shouldn't be hardcoded. It should be a default  filter by Internal Locations and groupby product.

To avoid unnecessary recomputations.

This reverts commit 37169c20.

Purpose
=======

we use to make proforma invoice to get payment before the creation of the real invoice. In the current odoo, the proforma state is too late. Because you have to confirm the SO to generate the draft invoice and so the proforma. But, if you do that, you have generated a subscription or a delivery order in the mean time. A proforma is actually a quote. In old ERP they used to make proforma to send a quote  and don't generate invoice number.

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

- Remove everything related to Proforma from accounting
    - Remove the configuration of pro-forma from account setting
    - Invoice form, remove "Pro-froma" button, stage, report title
- Add proforma configuration option in sales setting under "Quotation and Sales" section
- In quote/sale, add Pro-forma under Print
- A pro-forma is a quote, but the title of the report is Pro-Forma and not Quotation
- button (secondary) on quotation form "SEND PRO-FORMA" to send proforma by mail attached with related report.
   - button
   - mail template
   - when preparing a quotation this button is visible but if even one invoice this should be invisible (as confirming SO doesn't generate invoice currently)

Move the post-install tests execution outside `Registry.new`, and add a flag on
class `HttpCase` to enable/disable the registry "test mode".

This allows a test to run actual transactions that will reload the registry,
which may be used to test the creation of `ir.model` instances, etc.

The library reset the time set when the date is changed.
Then it was not possible to set the time then set the date
and expect the widget to close since the time will be reset
to the default value.
Instead we use the library behaviour and add a 'close' button
for the datetime widgets.

Closes #14454
opw-692002

We store quantity available to avoid numerical inconsistencies. For
exemple, with a rounding of 1e-6:
- `product_uom_qty` = 0.058824 (stored)
- `quantity_available` = 0.058823999999994 (not stored)

The dependencies of the field are fixed from v10.0.

opw-704775

Purpose:
========

A blanket order (it's an agreement with a vendor) is not a call for tenders (you aks several vendor to provide you an offer) but they are regrouped under the category "Calls for tenders" in the Settings of Purchase which should be changed .

Specification:
==============

- Change the setting option for 'Call For Tenders'
- Change 'Purchase Requisitions -> 'Purchase Agreements'

The library needs to have a 'relative' positioned parent to place
the datetimepicker correctly.
We don't do that in the template
anymore because it was not working in all the cases.
The template which instantiates the datepicker should define
a parent in position 'relative'.

Purpose
=======

It's hard to find all the menu items dedicated to products & pricing:
- create a product
- set up a discount
- change the pricing
such recurring actions are related to each other but you need to go to different menus: e.g. to edit pricelists you have to go to settings while editing your pricing is a business operation.

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

make one menu item like in ecommerce: CATALOG

Also clean reporting and configurion menus a bit...

Details
=======

Sales menu rearrangement :

Dashboard
Sales
Invoicing
    Orders to Invoice
    Orders to Upsell
Leads Management
Catalog (takes straight to products if no access to variant, pricelist or coupons)
    Products (move from Sales)
    Product Variants (move from Sales)
    Pricelists (move from Config)
    Promotion Programs (move from Config)
    Coupon Programs (move from Config)
Reporting (reorder items, from leads to sales)
    Leads
    Scoring Page Views
    Opp. Assignment Analysis
    Partnerships
    Pipeline
    Activities
    Phonecalls
    Sales
Configuration
    Settings
    Sales Channels (move up)
    Leads & Opportunities
    Sales
        Quotation Templates
        Report Layout Categories
        Payment Methods (if online quotation installed)
        Delivery Methods (move from Config > Delivery)
    Products
        Attributes
        Attribute Values
        Internal Categories (rename from Product Categories)
        Units of Measure
        Unit of Measure Categories
    Pricelists (remove)
    Delivery (remove)

If the data is available in the current context it should be passed to
_select_seller. The calls to _select_seller throughout the lifetime of a
purchase should be consistent (as possible) or the result of
_select_seller could be inconsistent when dealing with multiple sellers
(product_supplierinfo).

Modify a few signature of private methods to pass available information.

Closes #11414

With the user who is trying to access and the record they are trying to access
to.
This way it is easier to understand the reason of the error.
Do not show record and user ids in the popup as it is a technical information.

Closes #13030

Was: last inventory first which is not very usable as soon as there is many inventory registered.

Closes #15324

- Create a manufactured Product A (sold as kit), invoicing based on
  delivered quantity.
- Create the associated BOM, e.g. contains 2 Products B.
- Create a SO with Product A, validate
- Change the BOM so it contains 2 Products C
- Validate the picking linked to the SO

The delivered quantity is not updated since the delivered products (B)
are not the same than the products of the BOM.

This should not be the case. Changing a BOM should not affect the
invoicing. To solve this, we simplify the check and only verifies that
all moves are done.

The same change is applied for PO.

Cross 2 one2many fields
Closes #15259

To be triggered on the fields that are used inside the computed field.
Was not very problematic before as the fields were not stored and recomputed
at each modification. It could be backported if needed.

Next commit will store these fields for performance reason, fixing the trigger
first is required.

Linked to #15259

If a database had no base module or no latest_version, mark it as incompatible.
This should not happen in standard but as we are considering local databases
that may be non-odoo, we should be more fault tolerant.

Done at #15305

When listing compatible and incompatible db (introduced at 96f703ff), a
connection is created on each db to check the version of the base module.

After checking the version, release the connection from the ConnectionPool to
allow some operations like dropdb or rename.

A private attribute of the library was used instead of doing it
with the public methods. Due to the lib update, it was broken.

If a database is not an Odoo database or is not the same version
Closes #15171

Closes #15284

Closes #15284

Before this commit, the field selector had an unique option to filter
the fields it displays: filters.searchable, which tells the widget to
only display the searchable fields (which is the default). Now there
are two more options:

- fields: an explicit list of the fields to use (if null, let the
    widget get the fields itself (this is the default))
- followRelations: a boolean which is true if the user can follow
    relation to build a field chain (default to true)

These options are needed by Web Studio in enterprise where domain
construction for form view attrs can only use fields which are in the
view and do not follow relations.

The "ModelFieldSelector" widget has a "filters" option which can
customize the fields which are displayed.

The "DomainSelector" widget has of course the same option it can
transmit to its internal "ModelFieldSelector" instance... but it
was documented as "fs_filters" instead of "filters".

Also, let the "ModelFieldSelector" document its own options and
sets their defaults (instead of the "DomainSelector" widget).

The JS module 'web.session' is already defined directly in the template.
When two modules have the same name, the second one that is read is
ignored, and a error is displayed in the console (in debug mode).

this commit introduces the '/history' command
for an operator during a livechat session.

When the visitor load a page, its url is added in
a cookie (kept only 1 day) in order to track his
visited web pages.
The '/history' command will ask the cookie content
and send it to the operator as a transient message
in the livechat channel.

Replace deprecated options for the updated version of the
bootstrap-datetimepicker lib.
Lazy load the library in the front-end as well in order to avoid loading
it in all the front-end views.

* toggle datetimepicker when field is clicked
* close datetimepicker when a date is chosen
* disable keyboard navigation in the widget to allow modification of input

from 3.0.3 to 4.17.42

From 2.8.1 to 2.9.0