- Create a product A with a sales price of 40
- Create a pricelist where product A costs a fixed price of 100
- Assign this pricelist to a customer
- Connect as the customer on the eCommerce

On the eCommerce, the price for A is displayed as: ~~40~~ 100.

We only display a price difference if the pricelist price is smaller
than the sales price.

opw-1885443

closes odoo/odoo#29141

- Create a product with 2 variants A & B
- Set a weight on the variants (btw, the weight field is not available
  on the template in this case)
- Create an invoice for A, validate

On the intrastat report, the weight remains 0.0.

The report clearly takes into account the weight of the template, not of
the variant. We use the product weight, and fall back on the template
weight.

opw-1913305

closes odoo/odoo#29178

- Create an invoice with a discount
- Validate
- Open the Intrastat report

The discount is not taken into account.

opw-1913155

closes odoo/odoo#29161

Without the full stack trace, it is very hard for the developers to know
why and where the record creation has failed.

closes odoo/odoo#29143

closes odoo/odoo#29147

Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.

closes odoo/odoo#29078

Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.

The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.

Closes #29023

We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf

This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.

Up to now,
the supported wkhtmltopdf version was 0.12.1.

The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.

There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.

To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.

This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)

opw-1907346

closes odoo/odoo#28864

Fixing it directly by commit since there is no es_AR on transifex.

The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.

opw-1907924
closes #28923

With an mrp user, add lots lines to mrp production order moves. Then,
try to delete one line, the dustbin icon does not appear.

opw-1908930

As the product_tmpl_id field is related one but not readonly, the creation
of production order triggers a write on product.product model

On firefox if we do for example:

ALT+GR + [ALT+GRable ´ key]

Firefox may send keys "AltGr" and "Dead" instead of just "AltGr".

This was possibly causing caret to go a position too low when writing
speedily with diacritical marks.

opw-1903865
closes #28739

Fine tuning of this commit:https://github.com/odoo/odoo/commit/7501691da9a9dae832b7d6e78c6a5f57fc983b5c
Fields signup_token, signup_type, signup_expiration are protected
When sending a quotation (mail template 'Sales Order - Send by Email'):
the token needs to be read (and sometimes written)

opw:1907157

We were using hr.contribution.register as a doc_model on the
product.pricelist report which makes no sense since it should show
pricelist informations

On to many open orders the + and - buttons will be pushed out of view.
This makes it impossible to close orders without checking out.

removed the access right that was granting the read access on invoices to any internal user, because there's no reason to do so.

Fixes #28486

The patch fixes the issue related to repeated orderline rerendering. It means
that if products of the order were printed before, those will not be rendered
again when new updates of order is sent to the kitchen.

Closes #28577

If cost(purchase_price) was 0, margin calculation was incorrect.
The function _product_margin didn't consider the use case
where the cost of the product was set to 0 on the line.

So before the fix it fallback on standard price instead of considering  a cost of 0.

opw:1890452, 1885587

Backport of 12.0 signature that was done at ff83dfbb60ce

Closes #28493

Consider the generation of an invoice for a SO having the following lines:
quantity | unit price | taxes | subtotal
----------------------------------------
       1 |        100 |   15% |      115
       1 |       -110 |       |     -110

Previously, the invoice wrongly received the type 'out_refund' instead of 'out_invoice'. This was because the code was only considering the untaxed amount.

Closes #28259
Fixes #26726

Co-authored by pedrobaeza

opw-1895508

When making a BOM with variants, printing the Bom Structure didn't
display the complete name of each variant.

opw:1902770

This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.

In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.

With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.

This is what is already done in most invoice or other accounting views

Closes #26578

The constraint introduced in https://github.com/odoo/odoo/commit/22f0da809e84618901b7ca4b78582abd64c03c55 raised in case the currency of the company loading the test data was also USD.

payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`

Closes odoo/odoo#28397

Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.

//Scenario to reproduce the issue (from customer ticket 1903497):

(for a company with USD as base currency)

1. Create a new bank journal for EUR payments

2. Create a new customer invoice for 90€

3. Create a new tax for the reconciliation model, price-included and amounting to 15%

4. Create a new reconciliation model using this tax

5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.

6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.

7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.

What is the current behavior that you observe?

Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.

Revert commits da2140b7, e65c8826 and 06cd145a. They
introduce an incorrect UOM.

The original issue was an `AccessError` due to the fact that the
employee chosen was not in the same company than the user. Therefore,
instead of changing the logic of the UOM selection, we make sure to
select the employee in the appropriate company first, then fall back on
any company then.

opw-1888299

When doing a name_search, if a current search is already specified through args,
do not replace it

Closes #26594

This commit extend commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7
When you have a cart on multiple session and confirm the card in one of them,
you could still access your cart from other session (note that you could not do
anything with it as it would be reset when adding product or changing qty).

Closes #28210

Check commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7

This commit is doing the same for website_sale_option as the optional product
is calling another route to add the product to the cart.
That route needed to be fixed too.

Closes #28209, related to #27508

- When using perpetual inventory valuation, the accounts used for scrap, manufacturing,
and inventory adjustment operations are set on the corresponding locations .
- In a multicompany environment, you will have a separate chart of accounts for each company.
- Account fields on locations are not property fields.
- Therefore, in order to separate the accounting of manufacturing, scrap, and inventory
adjustment operations, you must use a location for each operation for each company.
- Set up one location for each company for scrap, production, and adjustment
locations, setting the company field on each.

Bug:
- When attempting to create a MO, inventory adjustment, or scrap order while signed
in to the second company, you will receive a permissions error on stock.location.

Fix:
- Now the right location is taken according to the company of the user.

Backport of this commit: c7526407

opw:1817339

In light of CVE-2018-18074, using python-requests 2.20.0 is recommended,
or any distribution-specific version that was patched.

See also https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18074

for accounts 3341, 3348, 141, 1388, 3388