I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).

What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.

Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).

closes odoo/odoo#133900

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

Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.

Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.

Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).

Closes #127846

closes odoo/odoo#133708

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

v13 backport of odoo/odoo#92117.

opw-2951837

closes odoo/odoo#99292

Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>

When there are too many (millions) of POS order lines associated to
opened POS sessions we get too many taxes, most are duplicated. This
causes a MemorryError.

Example queries from a real DB:
```
> select count(distinct r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_
 line_id = l.id where s.state != 'closed'
+-------+
| count |
|-------|
| 24    |
+-------+
> select count(r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_line_id =
  l.id where s.state != 'closed'
+---------+
| count   |
|---------|
| 2504539 |
+---------+
```

opw-3295467

closes odoo/odoo#124173

X-original-commit: 45d19b265033aa626e110e51d8b1d01408717a3e
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>

Backport of d02851d5

---

On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
  1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock

Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.

After:
The qyt_available for P1 is 5.

closes odoo/odoo#123244

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

[FIX] account_bank_statement_import: use the journal's company currency if none is defined in the journal

closes odoo/odoo#121293

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

Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.

Bonus point: tests no longer need to be imported in the `__init__.py`
file.

closes odoo/odoo#121150

Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>

mimic what is done for `odoo.addons` __path__.

closes odoo/odoo#121045

Signed-off-by: Christophe Simonis <chs@odoo.com>

Before this commit:
Files that should be ignored in the manifest but aren't (js library for example)
it can happen that files have huge lines, the regex to substract the
comments will overuse memory.
For example, a file of 13M with a line of more that 8M characters, the
memory consumptions peak at 1.7G

The results might be different, but it's an acceptable compromise

closes odoo/odoo#120111

X-original-commit: 0e56e4a7
Signed-off-by: Thibault Francois <tfr@odoo.com>

When we compare majorless scripts we must ignore the Odoo version.
Otherwise a module upgrade without major Odoo upgrade would fail to run
local scripts majorless scripts. That's what happens for example when
users click the upgrade button of a module.

Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder
for upgrades.
```
11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch)
     1.0 <      2.0 <=     2.0 -> True  (check with this patch)
```
While still: upgrade from `11.0.2.0` to `12.0.2.0`
```
11.0.2.0 < 12.0.2.0 < 12.0.2.0 -> False (before this patch)
     2.0 <      2.0 <=     2.0 -> False (with this patch)
```

closes odoo/odoo#119147

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

closes odoo/odoo#117886

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

Chrome 111 enabled checking of websocket origin: if the WS connection
sends an Origin head which is not whitelisted with the new
`--remote-allow-origins` switch it is rejected.

Turns out websocket-client (amongst others) *does* send an `Origin`,
which trips the check, and means tours immediately break when trying
to run them as Odoo's test harness is unable to connect to (and
control) the devtools.

Suppress sending `Origin` to fix the issue.

Note: this also prevents using the remote developer tools by opening
the devtools URL, user needs to go through chrome://inspect from the
client and find / select the headless browser from there.

Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39

Chrome tracker issue: https://crbug.com/1422444



closes odoo/odoo#114930

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

If an user tries sending a invoice using an invoice address and a
delivery address through snailmail, it would result in a traceback.
This is due to the invoice address record not having a name.

closes odoo/odoo#109681

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

If the IBAN includes a non-ASCII alphanumeric character and has just the right length, the IBAN validation crashes with a KeyError before validation can take place.

Fictional example: The supposed IBAN code "Bank München-Wiesn GmbH" gets normalized to "BankMünchenWiesnGmbH"; a string that starts with a valid country code ('BA', ie. Bosnia-Herzegovina) and happens to have the same length as Bosnia-Herzegovina's IBAN format (20 characters). Normally this erroneous IBAN would've been rejected as invalid, but Python throws a KeyError when trying to convert 'ü' to an int right before the validation step.

We therefore need to also check if all characters in the IBAN code are within the expected range, namely [a-zA-Z0-9] (strictly speaking, the IBAN's specification range is only [A-Z0-9], but we can be lenient since Python's `int()` is case-insensitive).

closes odoo/odoo#108338

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

Followup of odoo/odoo#110592

- Incorrect 0% soportado fp mapping
- Homogenize new tax names for import and intracommunity
- Incorrect tags for services import. And it should be both supported
  and subjected.

closes odoo/odoo#108868

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

- Added tags for the new Modelo 303 tax grids: 150, 152, 153, 155, 156, 158
- Added new 0% and 5% taxes (used for ceratain food and electricity)
- Added new 0% and 0.62% Recargo de Equivalencia taxes
- Added fiscal position and Modelo 303 tag mappings for all new taxes

References:
- https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_23/DR303e23.xlsx
- https://www.boe.es/buscar/doc.php?lang=es&id=BOE-A-2022-22685

Thanks to @pedrobaeza for the input

task-2993087

backport of b4cd54a3

Part-of: odoo/odoo#108868

Before this commit, some tag would not display correctly in the tag list of eLearning

This commit fixes this behavior

closes odoo/odoo#108041

closes odoo/odoo#111692

Related: odoo/enterprise#35003
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Don't limit on the first directory found in the upgrade-path.

It follow the same behavior regarding scripts found in the `maintenance`
directory and the ones in the local `upgrades` directory of modules.

opw-2868713

closes odoo/odoo#104887

Signed-off-by: Christophe Simonis <chs@odoo.com>

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>