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#107014

X-original-commit: 4abc7df7
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@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#107025

X-original-commit: 496f67ce
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this commit, a deadlock caused the editor not to restart
correctly when there is an invisible element on a page. The error is
visible by following these steps:

- Edit a website page
- Click on the footer
- Toggle off the page visibility option
- Click on the navbar
- Change the template
- The editor has to restart so click on "OK"

=> The Odoo top bar stays in edit mode and the user is not able to
modify the page.

Technical information:
When entering edit mode via the URL (enable_editor) the `WebsiteNavbar`
is not yet `ReadyForActions` because it is waiting for its sub-component
`EditPageMenu` to start edit mode. Then invisible snippets options start
(so the `VisibilityPageOptionUpdate` too). But for `isShown()` to work,
the navbar must be `ReadyForActions`. This is the reason why we can't
await for `isShown()` in the start of the option, otherwise we would
have a deadlock. On one hand the `WebsiteNavbar` waiting for the
invisible snippets options to be started to be `ReadyForActions` and on
the other hand the `VisibilityPageOptionUpdate` option which needs the
`WebsiteNavbar` to be `ReadyForActions` to be started.

Related to opw-2971181

closes odoo/odoo#103783

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

Since [this commit] it is visible that there is a race condition in the
editor. The race condition was caused by a call for an update of the
option visibility during the save, but the options may be in the
destruction process. This commit prevents the visibility of the options
from being updated when the option destruction process begins.

Steps to reproduce the bug fixed by this commit:
- Drop 2 times the image - text block on a page
- Drop a popup block
- Save

=> During the save, a traceback occurs.

[this commit]: https://github.com/odoo/odoo/commit/686e011f9b54bcfe93cc22db24435d2ca9213664

Related to opw-2971181

Part-of: odoo/odoo#103783

Before this commit, the popup snippet was not displayed correctly if it
had to be displayed on all pages and the footer was a slide hover
footer. This commit just permits disabling the footer effect while the
popup is displayed.

Steps to reproduce the bug:
- Drop some block on a page
- Set the the footer Slideout Effect to "slide hover"
- Add a popup and set it to be displayed on all pages
- Save

=> The page is blocked when the popup appears.

opw-2971181

Part-of: odoo/odoo#103783
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: qsm-odoo <qsm@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#107007

X-original-commit: cb9dbcb9
Signed-off-by: Tiffany Chang <tic@odoo.com>

Incorporate Ulises Rivadeneyra (UlisesRivadeneyra) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr

closes odoo/odoo#106938

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Apps have a "learn more" button which is redirecting to the given
website/URL.
The website is a field of the `ir.module.module` record, typically set
on enteprise apps in this file [1].

But the apps without a website are incorrectly showing that button.
Clicking on it will redirect the user to a `/false` 404 page, except in
16.0 and later version where it will simply do nothing.

Seems like there was an error introduced at some point, I didn't dig
into a complete history check but [2] could be a start.

[1]: https://github.com/odoo/odoo/blame/11d023f068d0308f2fa2de45f932f61a95086c6b/odoo/addons/base/data/ir_module_module.xml#L16
[2]: https://github.com/odoo/odoo/commit/7f9e7f0c961106fe13419166f112007f2d04e6ac#diff-c6e4af323e7ca3fe9d069fa98cd5da2f18ba606b8e4262005a79d2c1e0890dc8R189



closes odoo/odoo#106702

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Previously (since https://github.com/odoo/odoo/commit/649e0f2d1aefed585c3cf2b0c96ff6004280de97

) it was only set when the invoice had taxes, and it was re-defined as many times as taxes.

closes odoo/odoo#106862

Signed-off-by: William André (wan) <wan@odoo.com>

The tooling has been introduce in later version of odoo.
It is a problem when somebody switches to older branches without
disabling the tooling as it would then try to commit the tooling config
files.

We just add a few lines in the gitignore to prevent this issue.

closes odoo/odoo#106878

Related: odoo/enterprise#34518
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Steps to reproduce the bug:
- Enable “package” option in the settings
- Create a storable product “P1”
- update the stock to 100
- Create a picking:
    - product : P1
    - Qty: 1
    - operation type: delivery
    - go to additional info > add a carrier
    - Mark as todo
    - update the qty done to 1
- Create a second picking with the same steps

- Create a batch picking:
    - Add the picking 1 and 2
    - Confirm
    - Go to “Detailed operation” tab
    - Click on “Put in pack”
    - add a “Delivery packaging”
    - Save
    - Click a second time on “Put in pack”
    - Select the same “Delivery packaging”
    - Save

Problem:
Traceback is triggered: “tuple index out of range”

When the “Put in pack” button is clicked, the “action_put_in_pack”
function is called, the move_line_ids which has no package or with
a 0 quantity done are filtered, in this case the 2nd move_line with
the product “P2” will be used, but the `_pre_put_in_pack_hook` function
is not called with its picking:

https://github.com/odoo/odoo/blob/14.0/addons/stock_picking_batch/models/stock_picking_batch.py#L229

But rather with the first picking, it will have no move_line because the
first move_line already has a quantity done at 1 and a package.
So we try to get a record in an empty array:
https://github.com/odoo/odoo/blob/14.0/addons/stock/models/stock_picking.py#L1312



opw-3067921

closes odoo/odoo#106332

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

While upgrade of a customer database, A P-type image
was being converted to JPEG image. It didn't allow to save
as direct conversion from P-type(palette) to JPEG. So, fix
covers conversion of such corner cases to first convert it
to RGB and then RGB can convert it to desired output format
opw-3043418

closes odoo/odoo#105549

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
  exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".

Related to opw-3056683

closes odoo/odoo#106794

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

Steps to reproduce:
- Setup product (
    cost 10$
    Storeable Product
    Standard Price Accounting
    automated valuation
    add account for price difference
)

- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill

Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)

After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction

Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard

opw-2822366

closes odoo/odoo#101809

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

Previously, it was only possible to upload a bill, so the partner_id was read
from the vendor in the imported file. Now, it is also possible to upload a
file to create an invoice, so we need to be able to decode the customer in
the imported file.

opw-3072989

closes odoo/odoo#106765

Signed-off-by: Laurent Smet <las@odoo.com>

This commit description is in three parts: a generic explanation, a real
use case and the solutions

**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
   Then, there are two possibilities:
   1. If such environment already exists in the environments list of the
transaction, we reuse it:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
   2. Else, we create a new one and store it in the transaction:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
   It means that its value won't be recomputed unless we delete it
   https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
   https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
   The functions are added in a stack. So, in the execution order, we
will
   1. Clear the current environment and the registry
   2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
   1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
   2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
   1. E1 is reset (but its lazy properties are not deleted)
   2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)

**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
  https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
  https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316


- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```

**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.

So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.

C1 a40511cd

closes odoo/odoo#106252

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

*: website_sale_wishlist

Commit [1] and [2] introduced test tours but did not mark them as test
tours properly, thus showing them to users (who are in debug=tests mode)
by mistake.

[1]: https://github.com/odoo/odoo/commit/7655bface7f9e9bae8579e14e9a87b4f4801cc33
[2]: https://github.com/odoo/odoo/commit/a0c33c5f896718d1c03a6a50c981d6d75ce0d169



closes odoo/odoo#106667

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

In large database with lot of user, the browser don't respond.

closes odoo/odoo#100106

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:

- Open an invoice
- Enter a long link without spaces in the terms and conditions field
- Save

Issue:
The word doesn't break and spans outside its bounding box, possibly
overlapping with the subtotal footer on the right.

Solution:
Add class `text-break` to the narration field.

opw-3050054

closes odoo/odoo#106359

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide

=> There is no active indicator.

Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.

Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide

=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).

So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.

[1]: https://github.com/odoo/odoo/commit/f7055d3dbabfbe471f490bd65c2032f5251f3f37



task-3040931
opw-3051615

closes odoo/odoo#103963

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

Before this commit:
1. Create PO with quantity 10, confirm (creates receipt-1)
2. Receive 2 quantities on first receipt (receipt-1), backorder (receipt-1 is 'done', creates receipt-2)
3. Receive 3 quantities on second receipt (receipt-2), backorder (receipt-2 is 'done', creates receipt-3)
4. Change quantity to 5 in PO
5. An exception is created on all receipts (1, 2 and 3)

In the scenario above, receipt-1 and receipt-2 are partial receipts that are set to 'done'.
It is not necessary to create an exception in these receipts when the quantity is changed to less than originally expected in the PO.
Since the system checks that the new quantity has to be equal or greater than the received quantities, the already received quantities cannot be impacted.

After this commit:
The exception is only propagated to the receipts that are not done.
e.g. in the example above, an exception appears only in receipt-3.

task-2648209

resolves #76297

closes odoo/odoo#76691

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

Before this PR Odoo don't pre-search on location.

closes odoo/odoo#97014

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

When creating draft deferred entries in a reconcilable account,
we should not attempt to reconcile them, because only posted entries
can be reconciled.

closes odoo/odoo#106524

Signed-off-by: William André (wan) <wan@odoo.com>

Current behavior:
When splitting the order in a pos_restaurant session, the order was not
correctly saved in the backend. It resulted in an order that still had
all the product of the original order and another order with the
correctly splitted products.

Steps to reproduce:
- Start a pos_restaurant session.
- Go to table A and add 3 products to the table.
- Go back to the floor screen
- Go back to the table A
- Split the order in 2
- Click on payment, and go back to the product screen without paying
- Click on the ticket button, and click on the order that was splitted,
  it still contains all the products from the original order.

opw-3061569

closes odoo/odoo#106358

Signed-off-by: Trinh Jacky (trj) <trj@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#106078

X-original-commit: 8b7a3941
Signed-off-by: Raphael Collet <rco@odoo.com>

If a MO has some operations and if there are some reserved quantities
from sub-locations, when creating a backorder, the consuming lines in
the backorder will not use theses sub-locations.

To reproduce the issue:
1. In Settings, enable "Multi-Locations"
2. Create two storable products P_compo, P_finished
3. Update the on-hand quantity of P_compo:
    - 2 x P_compo at WH/Stock/Shelf 1
4. Create a bill of materials BM:
    - Product: P_finished
    - Compo: 1 x P_compo
    - Operations: add a new one
5. Create and confirm a MO:
    - Bill of materials: BM
    - Qty: 2
6. Check the availability
    - It reserves two P_compo from WH/Stock/Shelf 1
7. Set the producing qty to 1
8. Validate & Backorder
    - The producing qty of the backorder is already set to 1
9. Open the detailed operations related to P_compo

Error: There is a reservation line for 1 x P_compo from WH/Stock/Shelf
1, which is correct, but its done quantity is 0 instead of 1. Moreover,
there is another line from WH/Stock with the done quantity set to 1.
This line should not exist.

When creating the backorder, because there is at least one WO, we set
the remaining producing qty on the WO of the backorder:
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L1501-L1506
When writing on such a field, an inverse method is triggered:
https://github.com/odoo/odoo/blob/402dfd0a53af74e64278ff8746326c024128a2ee/addons/mrp/models/mrp_workorder.py#L221-L225
This method will update the producing quantity of the backorder and
generate the SML that consume the components
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L993-L998


However, we write the producing quantity of the WO before the quantity
reservation on the backorder. Therefore, when generating the consuming
SML, because there isn't any reserved quantity, we consume the
components from the default location (this is the reason why there is a
SML with a done qty from WH/Stock). Later on, we will unassign the
initial MO and reserve the backorder (and here is the reason why there
is a second SML from WH/Stock/Shelf 1)

The solution is an adapted backport of [1]

[1] 1180b6f7

OPW-3020189

closes odoo/odoo#106147

Related: odoo/enterprise#34179
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

update to this PR[1]

BUG:
some discounts are still displayed on the middle of the order

FIX:
move all discounts to the end

[1]:https://github.com/odoo/odoo/pull/102700


opw-2985632

closes odoo/odoo#106322

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

closes odoo/odoo#105518

Signed-off-by: Olivier Dony (odo) <odo@odoo.com>

closes odoo/odoo#106424

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

In Factur-X, there is no way to represent a tax "price_include" because
every amounts should be tax excluded.

Currently in Factur-X, a line with a tax price_include = True will be
incorrectly exported. Indeed, the Factur-X.xml is generated by setting the
GrossPriceProduct as the price_unit. In Factur-X, this amount (and the others
in the line details) should be tax excluded. Thus, it's wrong to set the
GrossPriceProduct as the price_unit.

To fix this, the GrossPriceProduct should be the price_unit if no tax
price_include = True is set, otherwise, the gross price = price_unit/(1+tax/100).

This way, the Factur-X file will be consistent with the norm.

Note that the import of a Factur-X xml will thus try to pick taxes with price_include = False,
and the price_unit will be tax excluded. If no matching tax with price_include = False is
retrieved, a tax with price_include = True is searched, if found, the price_unit is
recomputed accordingly. In both cases, the lines subtotals are the same.

opw-3032382

closes odoo/odoo#105276

Signed-off-by: William André (wan) <wan@odoo.com>

Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:

(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)

- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button

=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.

opw-2967706

closes odoo/odoo#105334

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

Before this commit:
 If we remove a payment line using an Adyen payment method,
 `pending_adyen_line()` return `undefined`.
 With the `_poll_for_response` still being executed,
 it will pop some JS traceback each call with:
 ```js
 TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
 ```

After this commit:
 No JS traceback loop

OPW-3032391

closes odoo/odoo#105716

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Commit 7fbb337e introduced performance slowdown when reconciling a
bank statement line with multiple invoices. This is due to the
compute function being called a lot of times and each time need to
trigger a search for CABA moves (even if the company do not use
cash basis).

This commit aims to not trigger the search if the company do not use
cash basis and add some domain conditions on indexed fields to speed up
the search when it's a cash basis company.

opw-3013391

closes odoo/odoo#105925

Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: Arnaud-Sibille <arsi@odoo.com>

If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.

Do not call this method if no module need to be installed.

closes odoo/odoo#106310

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit: if one product in one of the previous orders is
archived, it won't load the order properly for order management.

opw-3035231

closes odoo/odoo#105952

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

On large database this can take 700 ms per moves. After a few ms.

closes odoo/odoo#97000

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@openerp.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#106313

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

Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104779

Signed-off-by: Josse Colpaert <jco@odoo.com>

The dimensions UoM of the carrier packaging is useless: it is not the
one used in the requests and there is not any conversion

To reproduce the issue
(Need delivery_fedex. Use demo data. Enable debug mode)
1. In Shipping Methods, edit 'Fedex US':
    - Package Weight Unit: KG
    - Debug Requests: True
2. Edit its Fedex Package Type:
    - Height: 1m
    - Width: 1m
    - Length: 1m
    - Package Code: YOUR_PACKAGING
3. Create a SO with a US partner and one product
4. On the SO
    - Add Shipping
    - Select 'Fedex US'
    - Click on 'Get Rate'
5. In Logging, open the request sent

Error: the dimensions of the packaging are expressed with "CM" but they
are not converted:
```xml
<ns0:Dimensions>
	<ns0:Length>1</ns0:Length>
	<ns0:Width>1</ns0:Width>
	<ns0:Height>1</ns0:Height>
	<ns0:Units>CM</ns0:Units>
</ns0:Dimensions>
```

When encoding the packaging in the request, the UoM defined on the
packaging (meter) is ignored. Instead, we define a length UoM depending
on the UoM of the weight and we don't convert any dimension:
https://github.com/odoo/enterprise/blob/e4fd13a0e073b9855864b7fabc26bc05b9a5fd19/delivery_fedex/models/fedex_request.py#L172-L178
There is even a `TODO` about the issue.

It will be the same with the other carriers. For instance, with UPS:
https://github.com/odoo/enterprise/blob/c9899f7860cd19c86f215d6dcea89f73b51433f3/delivery_ups/models/ups_request.py#L98-L102


We use the UoM of `ups_package_dimension_unit` and do not convert the
dimensions.

We can't implement the dimensions conversion on stable versions, since
it will break all existing packagings. So, as temporary solution, we can
simply hide the useless UoM defined on the packagings.

OPW-3053048

closes odoo/odoo#105308

Related: odoo/enterprise#33754
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>