In case we are not uploading a file but add a slide based on google doc url
or youtube link, post['datas'] is not set and the code will crash.

Javascript don't check the onError, so the user never see the error and wait
 that nothing happend.

ERROR: column reference "action" is ambiguous

This commit closes #13839

[FIX] *: do not use groups when extending an asset bundle
Using groups when declaring an extension of an asset bundle leads to a
different generated asset bundle according to the user's group. This
is not something we want because a dynamic asset bundle's content
means that it could (and it does) trigger unwanted cache invalidation.

website_event, website_blog, website_forum and website_sale add
functions to . These functions are bound to
server side qweb nodes protected by groups. We can always add the
functions; if a user tries to use the routes he should receive a
traceback because of lack of access rules

website_blog adds a  module, but is guarded by
the presence of a node in the DOM. We use the same logic to guard the
module added by website_sale with the  node.

website_gengo is working as expected.

`tax_amount` is not defined here, making it impossible to remove an
order line...

- Create a tax:
  Fixed amount: 10
  Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product

The total price is 210 instead of 200.

opw-779696

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

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 ~

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

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

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

opw-777652

get_param return string, but timedelta wait a integer

Commit https://github.com/odoo/odoo/commit/5afb5ecd04cf49be6bedb655b187b19a65e1e02d#diff-1c14accbe350f7a177b3e81e5846861bL1363
removed the call to `_map_tax_fiscal_position`. Fiscal positions are not
applied anymore...

Instead of applying the fiscal position in the `compute_all` method as
it used to be, we apply it just before the call. This mimics the
behavior of SO/PO/Invoices, where the taxes are changed directly on the
order line.

Closes #20315

When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text

The typed text did not replace the selected text but was instead put
at the front of it.

5afb5ecd rewrote the tax computation
in both account and point_of_sale to fix complex tax computations but
it no longer allowed negative prices in the point of sale.

opw-778013

var is function-scope (not block-scope) so this happens to work, but
it's confusing.

Before this commit, a portal user would land on /web after login in with oauth.
He would then just see the "Website" app.
He should then click on it to land on website instead of landing directly on it
after login in, which is not convenient, especially since theses users doesn't
know Odoo (in case of sale customers manually created for instance).

Now, if users has no 'base.group_user' right, it will be redirected to the
website directly instead of /web.

- Create a tax included of 21 %
- Create a product sold 7.00, set the 21 % tax
- Add the product in a SO

Amount w/o tax: 5.79
Amount tax: 1.22
Total: 7.01

We defer the base rounding to the end of the method so that the rounding
doesn't impact the tax computation of included taxes.

Complement of 6e46ba7b

opw-777221

Could not add a test as the qweb js testsuite is broken and it's xml
test files have been modified in order to test qweb.py specific cases.

    We have problems when trying to validate our EU VAT report because some vat number are wrongly encoded in Odoo.
    There are 2 problems:

    1) We use vatnumber library to check the validity of the VAT number entered by the user on website.
       That library removes the following characters '.' and '-' in order to perform the check and
       thus can return True for a number like 123.123.123.13 or -123-3454-34
       And those VAT number are then saved in our database but are rejected by the state
       as VAT number should only contains alphanumeric character
    -> Solution: prevent entering vat number with other characters than alphanumeric for users that are located in EUROPE!

    2) Usually VAT is prefixed by country code, however some people in europe managed to bypass the system
       by prefixing their VAT number with CC instead of their country code, CC is consider valid in odoo
       (it means Country Code) but is not a valid European country code in general, which means that those
       people that should have pay some tax have not. Which is a huge problem.
    -> Solution: prevent the use of CC as country code by the user when entering a vatnumber only if the user country is in EUROPE!

    source: https://en.wikipedia.org/wiki/VAT_identification_number

opw:772621

opw-774286

*Before this commit:
On checkout, you can enable a step to force user to have the General Terms of
Sale checked to continue the checkout. Checking/Unchecking will correctly
disabled/enabled the button.
The checkbox is already checked at page load (on the template).
BUT, if the template has been modified to set the checkbox as unchecked at load
(eg the user removed 'checked="checked"' from the template), the button will
still be enabled even if the checkbox is unchecked.

*Now:
No matter if it is checked or not on the template, the button will
correctly be enabled/disabled regarding the checkbox state at load.

Don't round the base amount at each step during compute_all of taxes.

-opw: 776986

Specifically, the command `(6, 0, ids)` should only unlink/detach the lines
that satisfy to the field's domain.

Test from #18440

opw-756983
Closes #18438
Closes #18440

Partial backport of 11.0 commit (https://github.com/odoo/odoo/commit/6ad2ae30354a77c0f898cb9cb5a859713061d71a)
to solve issue 774152. Note: it has to be forward-ported as
implementation has been improved to handle mass mailing cases.

When an user triple-clicked on a paragraph and then typed text, the
paragraph was removed instead of its content (so the new text was
added at the beginning of the next paragraph).

See: http://stackoverflow.com/questions/38467334/why-does-google-chrome-always-add-space-after-selected-text

Origin of the fix: the snippet background image did not change the background image.
This was due to commit a14f89c8 which wraps the snippet's content into a table for outlook display compliance

This issue is fixed here, with the modificaion of the background snippet option.

OPW 772442

In some case, user set a currency on the journal which is the same as the company currency. In that case, the field taken was amount_currency which should not be the case.

OPW 775123

When an element is placed multiple times in a page, it is saved only
once. Unfortunately, when a view was divided in multiple editable
parts (XML branding), only one of those parts were saved.

When editing the content of a <label/> which has XML branding (first
DOM element which is editable in its hierarchy), a <p/> element was
added inside. This behavior is there to automatically add <p/> elements
in empty editable <div/> / <section/> elements on edition. This should
however not apply on <label/> elements.

This fixes a bug when pasting text in a paragraph, it was always
creating a new paragraph for no reason.

Suppose the correct computation:

        seq | amount | incl | incl_base |  base  |  amount
        ----------------------------------------------------
          1 |    10% |    t |         t |  100.0 |     10.0
          2 |    10% |      |           |  110.0 |     11.0
          3 |    10% |    t |           |  110.0 |     11.0
          4 |    10% |      |           |  110.0 |     11.0
          5 |    10% |    t |           |  110.0 |     11.0
        ----------------------------------------------------

with an initial amount of 132. Without this commit, the base amount was computed by:

132 / 1.1 / 1.1 = 109.09

instead of:

132 / 1.2 = 110.0

see task: https://www.odoo.com/web#id=34471&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720

Was PR #18275

This commit closes #19672

8ac39287 introdcude a way to export the source terms not located inside an
addons module (e.g. error messages in openerp/service/models.py)

0529a7f9 fixed a bug in the get_module_from_path with addons path with similar
names.

The above commit introduced a regression making files located outside of an
addons path to be wrongly considered as a module
e.g. openerp/service/models.py used not to match any module and was considered
correctly as belonging to base module
After, 0529a7f9, '~/openerp/service' being different than '~/openerp/service/'
the module was considered as 'models.py' (which is incorrect).

Compare correctly both parent path to have a correct match

Fixes # 19907

This commit closes odoo/odoo#19267