Before this change, the lots info of the products that are shown in the
invoice report were always computed, no matter if they were printed or
not. It is always computing the lots information, no matter if it will
be printed or not

With this change, the lost info only is computed when is actually used
and will be printed: that is when the user has the
sale_stock.group_lot_on_invoice group.

closes odoo/odoo#97348

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The setup:
* activate multicurrency and a secondary currency, for example the DKK.
  Make sure the exchange rate is not 1.
* in Settings - Sales - Pricelists, activate Advanced Price Rules
* create a new DKK pricelist with the following settings:
  * Compute Formula
  * Based on Sales Price
  * Discount 42% (or any another value)
  * Rounding Method 1.00
  * Apply on All Products
  * Min Quantity 10

Steps to reproduce:
* create a new sales order
* set Pricelist = the DKK pricelist you created
* add a product and set the quantity to 10

You should see that the total, after application of the pricelist, is
not rounded.

Cause:
The price is being rounded before conversion to the pricelist's
currency.

Solution:

Finetuning of b7ec0a2e
to make sure the pricelist base price is consistently rounded
before applying the rule formula (surcharge, margins, rounding, ...).

Previously, the price given to _compute_price was:

* in the pricelist currency if the rule is based on another pricelist
* in the product currency if the rule is based on the sales price
* in the product cost currency if the rule is based on the cost

Now, the price given is always in the pricelist currency.
This modifies the API of the method in stable (modifying the currency
of the price input), but is quite a logical change and required to fix
the issue at hand.

Note:
The issue is fixed as of v15.2

opw-3002376

closes odoo/odoo#102920

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Without this change, upgrades would generate the `pos_config_main`
record even in dbs with otherwise-well-organized structure.

Also, it might cause issues[^1] hard to solve otherwise.

[^1]: https://upgrade.odoo.com/web#active_id=421039&cids=1&id=421039&menu_id=107&model=upgrade.request&view_type=form



closes odoo/odoo#107609

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.

After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.

closes odoo/odoo#106906

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

In order to pass the validation of the snailmail provider, the margins
are required to have nothing but white pixels. To avoid letters being
stuck until their layout is fixed, we fill the margins with white.

closes odoo/odoo#106791

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Backport of
https://github.com/odoo/odoo/commit/274dd3bf503e1b612179db92e410b336bfaecfb4


(v15)

Steps to reproduce:
- create a product with tracking = 'lot'
- create a receipt for the product with a done qty > 1 for 1 lot
- change tracking of product to 'serial'
- go to "Update Quantity" and try to update the existing quant
  inventory_quantity to 0

Expected Result:
It's possible to make the quant 0

Actual Result:
Confusing Validationerror occurs:
"A serial number should only be linked to a single product."

Error occurs because the corresponding Inventory adjustment location is
not allowed to have more than quant.quantity > 1 so the user is never
able to remove more than 1 of the quantity from their stock.

opw-3062017

closes odoo/odoo#106996

Signed-off-by: Tiffany Chang <tic@odoo.com>

On the ticket https://github.com/odoo/odoo/pull/101547

 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.

closes odoo/odoo#106301

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

PG12 introduced an optimization for CTEs that automatically inlines
CTEs if they are only refered once in the parent query. Prior to that
CTEs were always materialzed, meaning that PG created a sort of temp
table on the fly to store the result of the CTE's evaluation.

Whereas this leads to performance improvements in general, in the
particular case of _select_companies_rates this inlining becomes a
performance bottleneck. This is because while the currency_rate CTE
is only refered once in both purchase_report and product_margin,
the join condition (cr.date_end is null or cr.date_end > ...)
requires evaluating the CTE's date_end subquery twice. This, combined
with the fact that in PG12 the planner goes for a Nested Loop JOIN instead
of a HASH Join in PG10 makes the performances of the whole query
much worse in PG12 than in PG10.

Adding an ORDER BY (or an OFFSET 0, the resulting plan is the same)
creates a kind of optimization fence that forces PG to evaluate the
subquery first using its own plan. This removes the need to rescan the
subquery each time the Merge JOIN filter has to be applied, which
is a good strategy in this specific situation.

The same result could be achieved by adding the keyword "MATERIALIZED"
in the CTE definition. The issue is that this keyword did not exist
in PG 10 so using it would require to check the PG version at runtime
from python.

Examples of query timings change before and after PR:

Number of POs | Before PR | After PR
      2000    |     7s    |    345ms
      7000    |     23s   |    1.1s

opw-2930578

closes odoo/odoo#98844

Signed-off-by: Raphael Collet <rco@odoo.com>

ref : https://github.com/odoo/odoo/commit/d3b482b1d6c9f19ff428b3918c0e09b11c87c873


more then 3 upgrade requests failed.

closes odoo/odoo#105627

Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

closes odoo/odoo#105630

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

On the pull request 101547 the message was not added to the pot file.
This commit adds it.

closes odoo/odoo#105407

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Using the already existing indexing on the model to slightly improve the perfomance.

closes odoo/odoo#105280

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.

Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.

Solution:
Raise an user error when trying to save the changes.

opw-3000886

closes odoo/odoo#101547

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:
 - Install website_sale_coupon
 - Load demo data
 - Create a promotion program that applies on the order
 - Go to the webshop and add 2 different products to the cart

Bug:
The line of promotion is in second place, instead of at the end.

Fix:
move the old sale order line to the end if it applies on all the order

opw-2985632

closes odoo/odoo#102700

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Since the provider only accepts A4 letters, prevent the user from using
non A4 formats by giving them an error when clicking the Send button.

closes odoo/odoo#105058

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

The valuation field of the product_id is company-dependent.
If the user validate the picking in multi-company context with his current company != picking company, then the checks may fail, and the account move can not be created.

closes odoo/odoo#104895

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Pingen does not support localized country names, as such we need to force English
locale.

closes odoo/odoo#104852

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

EXPLAIN ANALYZE SELECT "stock_move".id
FROM "stock_move"
WHERE ("stock_move"."created_purchase_line_id" in (24065, 24066, 24081, 24082, 24083, 24084, 24085, 24086, 24087, 24088, 24089, 24090, 24091, 24092, 24093, 26121, 26487)) and ("stock_move"."company_id" in (1))
ORDER BY "stock_move"."sequence" ,"stock_move"."id" ;
Goes from 2231.021 ms to 1ms on a database with 2.800.000 stock_move.

closes odoo/odoo#100035

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.

How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice

Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.

closes odoo/odoo#91470

Task: 2852452
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

When there are many `calendar.event`s (700K+), MemoryError happens when they are tried to be sorted
before returning them in `get_recurrent_ids` method.

[upg-377987](https://upgrade.odoo.com/web#action=150&cids=1&id=377987&menu_id=107&model=upgrade.request&view_type=form)
Traceback from the upgrade request:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/maintenance/migrations/base/tests/test_mock_crawl.py", line 220, in crawl_menu
    self.mock_action(action_vals)
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/maintenance/migrations/base/tests/test_mock_crawl.py", line 347, in mock_action
    mock_method(model, view, fields_list, domain, group_by)
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/maintenance/migrations/base/tests/test_mock_crawl.py", line 368, in mock_view_form
    records = model.search(domain, limit=3)
  File "/home/odoo/src/odoo/12.0/odoo/models.py", line 1581, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/home/odoo/src/odoo/12.0/addons/calendar/models/calendar.py", line 1802, in _search
    events = self.browse(events.get_recurrent_ids(args, order=order))
  File "/home/odoo/src/odoo/12.0/addons/calendar/models/calendar.py", line 1261, in get_recurrent_ids
    return [r['id'] for r in sorted(result_data, key=key)]
  File "/home/odoo/src/odoo/12.0/addons/calendar/models/calendar.py", line 1259, in key
    for v, desc in vals_spec
  File "/home/odoo/src/odoo/12.0/addons/calendar/models/calendar.py", line 1259, in <listcomp>
    for v, desc in vals_spec
MemoryError

The issue is happening in the `key` function when data is being sorted before returning it. In this function to compare events for every key a list is returned.
Returning a list for every element leads to a memory error because lists over allocate memory when they are created to make Time complexity of [appending to a list O(1) in amortized time](https://stackoverflow.com/questions/46664007/why-do-tuples-take-less-space-in-memory-than-lists

)
Over allocating memory a few times would not be a problem but given that this db has 700K+ `calendar.events`, over allocation causes a memory error. That's why it is better
to return tuples instead of lists, which do not over allocate because they are immutable, which will resolve the MemoryError.

closes odoo/odoo#103182

X-original-commit: c53081f1
Signed-off-by: Christophe Simonis <chs@odoo.com>

When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.

closes odoo/odoo#100771

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.

# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."

# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()

OPW-2982004

closes odoo/odoo#100064

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

closes odoo/odoo#104196

Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover
- Click on the "guides" tag of the "Buying A Telescope" blog

No blog is displayed. This was because the top banner post is not shown
when the posts are filtered. Basically, once filtered, a blog post was
always missing.

Related to opw-2882492

closes odoo/odoo#93680

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover

The URL to which we are redirected when we click on the blog of the
post presented at the top of the page leads to an error.

Indeed the URL of that link is something like "/blog?blog=blog.blog(2,)"
because of the template wrongly using the 'blog_url' QueryURL which is
defined in the case where we are rendering a blog page where no specific
blog is selected. We define that as `QueryURL('/blog', ['tag'], ...)`
but then parts of the template used it like this: `blog_url(blog=X)`
thus generating an URL like "/blog?blog=blog.blog(2,)". Adding "blog" to
the list of params would not be right as would create "/blog/blog/2"
which is still wrong as we want "/blog/2". And of course the "/blog"
prefix in the QueryURL definition is needed in case we only specify a
tag via `blog_url(tag=X)` (we expect /blog/tag/X). Patching QueryURL or
making blog_url a custom function instead of a QueryURL instance could
be a solution but it was judged not stable enough. We'll do that in
master. Here we only support "/blog?blog=blog.blog(2,)" URLs.

Note that many parts of those templates do not use the `blog_url`
function and simply build the URL by hand, which is why the bug only
occurred for a very specific set of blog options.

opw-2882492

Part-of: odoo/odoo#93680
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>

Backport of #83422

closes odoo/odoo#104094

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Have the following taxes:
- Tax A: 15%, included in price
- Tax B: 21%, included in price

Create a product P with list price 115 and tax A

Have a fiscal positions FPOS configured with:
- Detect Automatically checked
- Country: Belgium
- Map tax on product: A -> B

Open a web shop session as guest, add P to cart
Go to checkout: Price total will be 115
Fill address details with Belgium address
Go to confirmation page

Error:
Price total will be 100. In the application of fiscal position the wrong
unit price is used

opw-2973879

closes odoo/odoo#101364

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.
Also make the Cover Page option mandatory due to the invoice being near
impossible to format for Pingen's validation needs. (Odoo 13 Only)

closes odoo/odoo#103385

Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>