The checkbox was there to activate autoplay... but was not doing
anything since the web_editor/website split.

When a pad is created programmatically (e.g. through a project task or a
note), the pad is empty when it is first displayed. It is necessary to
edit the record and save it in order to be able to see the content.

This is because the pad is normally initialized by the JS layer, at the
first edition, thanks to a call to `pad_generate_url`. Therefore, a
programmatic pad creation won't initialize it.

opw-685826

The dashboard instantiates an action manager for each view it has to display.
It then replaces the do_action() function of those action managers by its own
one, forgetting to pass the second argument 'options'. Thus, when do_action was
called by a view of the dashboard (e.g. a button in a list view), it was called
without the options.

The quantity event handler is not correctly unbound when its action
is deleted, resulting in multiple window.prompt asking the quantity
of the products if you go mulitple times trough a view when a widget
implementing the barcode thing is used.

There seems to be a bug in the framework ("barcode_scanned" events
are registered the same way than the "keypress" one on core.bus
but they don't have suffer from the same issue).

The .dropdown is in a .btn-group environment while a .btn-group can
only contain .btn or .btn-group elements.

This induced problems where the m2o options covers the full overlay
environment, preventing clicks on the customize dropdown.

When an onchange return a NewId for a many2one, the expected result is
a False value.
It appear for computed many2one that can return currently created
record like `res.partner.commercial_partner_id` field.

orderpoint.lead_type should be 'supplier' instead of 'purchase'

opw-687311
Closes #11389

Currently some customers receive the automatic notification 'Quotation
viewed by customer'. This should not be the case as this notifciation
is purely internal and should only be sent to the quote responsible.

Notification is now a note with the responsible being directly in the
recipients.

Conflicts:
	addons/website_quote/controllers/main.py

Backport of 14f07cb9
opw-687957

When doing a reconciliation, make sure that the tax amount is properly
rounded to the currency precision. Otherwise, if the rounding policy of
the company is "round globally", the amount recorded won't be rounded.

opw-688399
Closes #13452

An issue arises in the following use case:
- Company rounding policy in "round globally"
- Tax excluded of 20 %
- Create a statement of 3.80 EUR
- Reconcile the statement thanks to the reconciliation widget
- Click on "Choose counterpart" in order to manually create a line to
  reconcile with the 3.80 EUR statement
- Add an amount of 3.17 EUR, and choose the 20 % tax

The widget creates an extra line of 0.00EUR . This is because the
remaining amount is 0.004.

The reason lies in the `monetaryIsZero` function. There is a hardcoded
decimal precision of 4, while it should be 2 for EUR.

We add an extra parameter to the function so it is possible to adjust
the decimal precision required. Only the problematic calls are modified
to avoid unnecessary intrusive modification.

Closes #13452
opw-688399

In some specific cases,it is necessary to call the `compute_all` method
and prevent any rounding to be done. This adds some flexibility in the
method to override rounding thanks to a 'round' context key.

Related to #13452 and commit 2e4777bb

opw-688399

According to RFC 7232 # 2.3, an etag must be wrapped in double quotes:

    entity-tag = [ weak ] opaque-tag
    opaque-tag = DQUOTE *etagc DQUOTE
    etagc      = %x21 / %x23-7E / obs-text
               ; VCHAR except double quotes, plus obs-text

Odoo didn't properly quote etags, which could lead to stripping or
failures when putting Odoo behind strict HTTP proxies.

Currently, when rendering a list view cell with a many2many we would
empty the list of ids, and fill it again once a name_get is resolved.

But in some instance, the code could use the data when it has been
emptied out.

For example, if we set the tax_id field (inside the order_line list view
inside the sale.order form view) as requred, if we modify the order line
and save directly (without clicking outside of the list view) we can get
an incorrect error saying that the "Order Line" is not valid.

It has been reproduced when saving with CTRL + SHIFT + S on google
chrome and firefox, and there have been reports that for some
configuration it also happen when clicking on the "Save" button.

This commit change the behaviour so the value is kept whilst the name_get
is ongoing, and just use a default "false" value for the name during this
interval.

closes #13478
opw-668067

Analogous to 6fde72abeacdac6e36a0c623c024252839f993ae but now instead
for the 'split' button.

Additionally this uses float_compare with the rounding set on the uom of
the operation to determine if there are any units left, which is more
correct.

opw-685908

When a stock.pack.operation gets created by a stock.picking, it will
have its pack_lot_ids set. This way the user has an overview of what
lots are available and how many of each are still left.

When splitting the stock.pack.operation these where lost. The still
unpacked stock.pack.operation would always have an empty pack_lot_ids
field. The reason for this is that those records where reassigned to the
newly created and packed stock.pack.operation.

This resolves the issue by copying pack_lot_ids that are still
available (qty_todo > 0) and assigning them to the original
stock.pack.operation.

opw-685908

In some cases, users change the sequence of base
views in order to have one applied before the other
e.g. when there is two inherited views doing
```
<tree position="inside">
...
</tree>
```
The priority of the views will have an impact on the
fields order in the tree.

On update, the change of priority done by the users
was overwritten, even if the priority of the view
was not defined in the XML code of the view.

The priority of the views should be overwritten only
in the case were the priority of the view
is specifically set in its definition.

opw-688470

A portal user couldn't change his address details if he was
of type `contact`

This happens because users usually
have no access to write their parent company.

opw-688192
Closes #13430

Before this commit, if we dragged a snippet and dropped it where we
began the drag, the snippet was removed.

The snippet options can define an on_remove method which was supposed
to be called when the snippet is removed. This was not the case since
the method was written so that the options were removed before the
on_remove method was called... (Un)fortunately, the on_remove callbacks
were not doing any critical job in current implementation. In saas-13
however, some elements will rely on this.

Closes #13387

Although we have been reluctant to perform this change, a specific
use case can cause customers to be redirect to the Odoo DPN url
with a GET request.

This happens when a Paypal Merchant account has the feature Guest
Checkout active; in that case, a customer can pay without having
a Paypal account (using only his credit card) and will *not* be
subjected to auto-return; as detailed here:
https://www.sandbox.paypal.com/be/cgi-bin/webscr?cmd=p/pop/help-account-optional
Request coming from that payment flow will always trigger a GET
request, causing the customer to be welcomed by a
405 - Method Not allowed
error on the Odoo server. The payment is normally correctly processed
through IPN, so this does not normally causes loss of data; however
this is not a nice way to welcome back your customer right after
they pay you.

Commit 8ad0c0f3 introduces back the base amount taken into account for
tax calculation. However, the way it calculates the amount is wrong in
several cases:
- the tax amount is a percentage
- the tax is calculated thanks to Python code

opw-686846

Received PDF signature by email on 2016-09-06, from
Aleš Ferlan <alefer89@protonmail.com>.

See opw-687914 for original PDF signature.

When selectionning a saved shipping address when setting the shipping
address of an ecommerce order, the country and state should be set
accordingly.

unrelated issue noticed when testing e0d4dd01

In 1ef52c9c the code displaying state of a given country was improved
for some incompatibilities.

But, if when setting the billing informations we choose to create a new
shipping address, the shipping state* would not be displayed even when it
should be (currently, if the shipping country is Australia or U.S.).

opw-687948

*a state being a subdivision of a country

Until 9.0 our psycopg2 DSN connection strings do not allow having
spaces within the db name, and passing some can cause duplicate
registries to be loaded.

Stripping spaces is a simple workaround until we actually support
spaces within db names.

Fixes #13078