When opening the POS in this specific case:
- Under Mozilla Firefox
- auto printing the receipt is True
- invoicing is True

Before this commit, when issuing an invoice for a customer, a Traceback was thrown to the user and the invoice was not downloaded.
This was because the invoiced parameter resolved before the printing action was.

After this commit, we constain the invoiced parameter to be resolved when the action returns.
There is no traceback, and the invoice is downloaded

OPW 777647

closes #20570

The `sale_stock.tour` failed in the case the admin was not
part of the group
`product.group_stock_packaging`
or the group
`sale.group_mrp_properties`

because then the sale order was working with the editable list,
which does not open a dialog,
while the test was relying on the dialog to be opened,
in order to close it.

The fix is simply to pass the fact to close the dialog if
there is none.

opw-779308

In Enterprise:
- Go in Settings > Technical > Mail > Templates
- Edit a template
- In the editor, upload an image
- Choose "Upload image without optimization"

You are sent back to the app switcher.

opw-778918

Location and Company are non-stored fields. Therefore, grouping by these
fields leads to a traceback.

opw-779564

Only products without company can have taxes of different companies

Closes #20256 
Fixes #20250

The link does not work anymore.
Even when it was, it did not provide any information as can be seen in
https://web.archive.org/web/20160608025556/http://www.buckaroo-payments.com:80/business/customers/online-payment/

Fixes #16987

Do not try to run `action_assign` on the next move if it is done or
cancelled. The issue is that `action_assign` will first unlink the
existing pack operations before creating new ones, and the system
forbids to unlink these ones.

To reproduce this issue:
1. Create a product, routes manufacturing and MTO
2. Create SO with that product
3. Go to DO and force assign then cancel the delivery
4. Go to Manufacturing order created and produce

opw 778897

Suppose a tax of 20% with price_included = True and apply this tax on 399.99:
- base = 399.99 / 1.2 = 333.32500000000005
- tax_amount = base * 0.2 = 66.665
- round(base) + round(tax_amount) = 333.33 + 66.67 = 400.0 (!= 399.99: WRONG)

-opw: 777925

In 7eab8e26 res.partner was converted
to the new API, at that point company_type was changed from a stored
field manually synchronised with is_company (through create/write
overrides) into a proper computed field.

However to make it "editable" it was simply marked as
"readonly=False", which means even though UI-wise it looks editable
editing it does not actually do anything (things work in the partners
form because there's also an onchange which updates is_company on the
fly).

Fix by implementing an inverse function and actually do this
correctly.

Fixes #20623

- Go to Maintenance Requests, Create
- Go to 'Equipment' field, 'Create and edit'
- Go to 'Product Information' tab
- Click on 'Vendor' field, 'Create and edit'

'Is a Vendor' field is False

opw-779200

Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.

Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.

~ Old API backport of 5d0d80af ~

Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.

Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.

(issue spotted by 11.0-nightly)

Closes #19812 #20596

Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.

Fine tuning of this commit: 51d072db

When clicking on the group of the Inventory at Date, the
product.price.inventory must follow the same order as the
read_group in stock.history.

opw:747857

- Create an asset, post one line.
- Go back to the asset => the button is green
- Click again on the line => the button is orange

There is no protection to prevent the user to post the same entry
several times (a new account move is created every time it is clicked).

We fix the JS widget, but we add an extra layer of protection at the
Python level.

opw-778756

Closes #20556
Closes #20557

Before this commit, when trying to access website_public_price from the backend (when adding this field to a view for example), a traceback saying that the website attribute on the request object was non existent was raised.

After this commit, we control for this and the field displays correctly

OPW 778586

closes #20536

Before this commit, when opening the POS in IE11, then the customer list, the list was empty.
This was due to condition that was wrongly evaluated as false due to the fact that IE11 apparently only wants ECMA5.1 to deal with constructing Date() from a string.

After this commit, we construct the Date() object with the right string, and the list of customers doesn't disappear.

OPW 776463

For reference:
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15

closes #20468

Display full variant name on manufacturing order print out

Closes #20471
opw-778514

Taxes tags for some localization have been rewrote in order to improve the taxes report.
However, these changes delete the existing account.tags on stable version.

These "[l10n_*] one tag per grid in tax reports" should target master instead of 9.0.

-opw: 777464

In some cases, vendor reference for payment may already exists.

For instance in Belgium, some suppliers provide recurring invoices which
contain the same communication for the payment. From the version 9.0,
the field Vendor refrence is used for payment communication and the
maching on bank statement.

So, in this case, we have to put the communication from the payment in
this field and, as explained just above, maybe the same as on another
invoice.

Therefore, this commit provides a hook to modify/disable this behavior.

Closes #20343
opw-777608

This commit is related to opw-771825

The access to the state of sale.order.line (related field) seems very slow for big sale order. Bypassing the related field and using the real field instead, improves performance.

Fixes #19824
opw-776928

When trying to get the pdf content in an IFrame, the url based on
ID was not found and then redirected to a rewritten URL eventually
with  wrong protocol (https became http). This causes a bug in
modern browser that doesn't allow mixed content if the base website
is in https. By using the slug in the URL, there is no redirection
and we avoid changing the protocol.
Thanks @Gorash and @nim-odoo

opw-777950

Before this commit, you was able to double click on the button when
are in registration flow. In this case, you subscribe 2 times and so
take 2x more seats, what can be annoying when you have a limited room.

In the same time, we fix the form in the form that generate
strange behaviour like some events not bubbled correctly.

The attendee form (into the modal) was inside the registration form.
$'attendee_form).on('submit') obviously failed due to this bad dom.

This commit closes opw-778191

Since Odoo 8.0,
the default stock input account for product categories
in the Canadian localization is set to
`214100 CANADA REVENUE AGENCY`

This is the case since this commit:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecL294
In which the account with the XML ID 2141_en
214100 Stock Received But Not Billed
has been renamed
214100 CANADA REVENUE AGENCY

In this very same commit, the account "Stock Received But Not Billed" has been moved to the account 217100,
under the XML ID chart2171_en:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecR447

While the default value for the products categories stock input account remained the same, the account with as code 2141:
https://github.com/odoo/odoo/blob/8.0/addons/l10n_ca/account_chart_template_en.xml#L8

This is an oversight. It was not meant that way. The default stock input account for products
should well be "Stock Received But Not Billed".

In addition, a stock account is supposed to be of type assets, and not of type liabilities.

I contacted @max3903, who was a contributor of the l10n_ca localization,
and who is therefore a better expert than me regarding the Canadian localization.
He confirmed me all the above findings.

opw-775413

When having a product with included taxes that are changed/removed with
a fiscal position, the price changes depending on if the pricelist's
discount_policy is with_discount or without_discount.

This commit aligns the without_discount behavior to the with_discount
behavior.

Note: the behaviour isn't 100% correct. The applied discount will be
      computed on the list_price, instead of the tax excluded
      list_price. If a price_surcharge is set, it will be wrong.

Supplements https://github.com/odoo/odoo/commit/0d56dca

When basing a pricelist on another pricelist in different currency
conversion was not being made correctly, since commit https://github.com/odoo/odoo/commit/6b3a808
that changes the pricelist_item on which the currency_id is set in
_get_real_price_currency.

Also align the _get_display_price's base_price to the
_onchange_discount's new_list_price in the case where the pricelist
depends on other pricelists that are in without_discount mode as well.

opw-777652

get_param return string, but timedelta wait a integer