### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact

You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)

opw-3007722

closes odoo/odoo#103545

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

Setup:

  - Add a checkbox to the sublist view of quotations with studio and save
  - In the chrome devtools, select a custom network throttling profile
    with 1s of latency

Steps to reproduce:

  First example:

  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Double click on the price field of the second line
  -> A traceback appears: `Cannot set properties of null (setting 'props')`

  Second example:
  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Click on the price field of the second line
  - Click on Save
  -> The same traceback is there

Cause of the issue:

  The checkbox field is implemented in owl and thus the
  owl_compatibility layer is used.
  Mounted is not called on the checkbox if a new rendering is being done
  cf: https://github.com/odoo/odoo/pull/75950


  Currently, it is possible to set a row mode before the previous call
  and rendering is done.

Solution:

  Use a mutex for each record to prevent simultaneous render

opw-2937444

closes odoo/odoo#101419

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
3. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO

Error: The qty received is 2, it should be 0

There is currently no code to handle the return of a dropshipped product

OPW-3030895

closes odoo/odoo#105185

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

When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
4. In Locations, edit WH/Stock:
    - Return location: True
5. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: WH/Stock
8. Validate the return
9. Go back to the PO

Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)

In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.

OPW-3030895

Part-of: odoo/odoo#105185

When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.

OPW-2955202

closes odoo/odoo#104346

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

Steps to reproduce the error:
- Install 'Maintenance'
- Select 'Maintenance' -> 'Request Maintenance'
- Create a maintenance request:
          + TH1: Save > Change stage to Repaired > 'Close date' =
Date.Today()
          + TH2: Don't Save > Change stage to Repaired > Save > 'Close
date' = blank

closes odoo/odoo#100777

Problem: App will show 'Close Date' blank
Expected: App will display 'Close Date' as Date.Today()
Solution: When Click on Save button -> Automatically get current date as end date
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

There are specific accounts that should be used for tax groups for
each version of the CoA

t-3059059

closes odoo/odoo#105648

Signed-off-by: John Laterre (jol) <jol@odoo.com>

Fixes a small but massive typo that prevents snailmail from working on
version 14 to 15

closes odoo/odoo#105707

Signed-off-by: Florian Daloze (fda) <fda@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#104819

Task: 2852452
X-original-commit: 1e336810
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

closes odoo/odoo#105638

X-original-commit: 68f29fda
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

closes odoo/odoo#105510

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Upon updates, the `active` field of `ir.ui.view` behaves differently
depending on whether the view is defined by using the `<template>` tag
or the `<record>` tag.

When using `<record>`, it behaves like any other field and gets updated
with the new value (notice that for qweb view, you should rarely rely
on this as if users customized those views with the website builder,
they are duplicated (COW)... updating the active field without migration
script would then be a source of errors).
When using `<template>`, it is not updated since [1], except for new
records since [2].

This commit adds a comment to the `active` field to help developers find
out about this difference.

See this [discussion].

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
[discussion]: https://github.com/odoo/odoo/pull/104836#discussion_r1013155860



Related to task-2963840

closes odoo/odoo#105524

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

Model `account.move.line` has extended `_name_search` to clarify `ilike` search.
However, the new domain replaces original domain, instead of making a friendship.

STEPS:
* add custom Many2one field to any form (e.g. SO)
* add domain for the field, e.g. ` [["parent_state", "!=", "draft"]]`
* try quick search for the new field

opw-3037878

closes odoo/odoo#105534

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

Steps to reproduce:
- install the "Extended Adresses" module;
- in the configuration menu --> countries, edit the street format for Belgium to "  %(street_name)s" (with whitespaces)
- create a new contact;
- select a contact suggested by the auto complete feature (for example Odoo)

Issue:
    Some letters are removed if we add whitespaces in the street format (street_name field has the value "e du Laid Burniat 5" instead of "Rue du Laid Burniat 5").

Cause:
    The function which splits the raw address taking into account heading characters.
    Therefore the function truncates whatever is in front of the first field of the street format which is normally the image of the address (street_raw).

    Example 1: (correct use)
    street_raw = "header Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Rue du Laid Burniat 5" --> OK (format address is properly configured to match with street_raw)

    Example 2: (incorrect use but desired behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Laid Burniat 5" --> truncation is expected (7 leading characters are removed) (format address is not properly configured to match with street_raw)

    Example 3: (incorrect use and unwanted behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = " %(street_name)s"

    street_name = "ue du Laid Burniat 5" --> truncation is not expected (1 leading character is removed) (format address is "properly" configured but with whitespace)

Solution:
    Remove whitespaces before street format when editing this field to prevent truncation of the field value.

opw-2964457

closes odoo/odoo#99224

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

This commit fixes an issue where if a ticket is free, the registration would
still "need to be paid" by the attendee.

This behavior is contradictory for a free ticket, so the attendee now has to
pay the ticket if it is not paid and is not a free ticket.

task-3012928

closes odoo/odoo#102996

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

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

closes odoo/odoo#105305

X-original-commit: 4344d399
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.

opw-2976261

closes odoo/odoo#105072

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

Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.

opw-2976261

Part-of: odoo/odoo#105072

Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.

Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled

Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.

Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.

opw-2976261

Part-of: odoo/odoo#105072

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

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

Currently, if the user uploads a facturx document whose move_type does not match the move_type chosen by the user, the document is not auto filled with the information contained in the facturx XML because of a restrictive check. Therefore, the document is empty and is sent to the OCR which acts as a backup.

Starting from this commit, we will remove this restrictive check. So, if the user uploads a facturx document, we will use the move_type define by facturx regardless of the move_type chosen by the user. This means that when we upload a facturx document, we will always use all the information that is in the xml to create the document and avoid using the OCR.

task-id 2961932

closes odoo/odoo#105287

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

Steps to reproduce:
	- get into an employee appraisal;
	- click on the smart button "No meeting" from calendar view;
	- edit it directly the meeting and save.

Issue:
	We will not find any new meeting on the smart button if we go back to the employee appraisal page.

Cause:
	When saving the appraisal from the edit view, an event will be created. Unfortunately, the `res_id` field (which allows it to be linked to a record in the `hr_appraisal` table) is not correct. The smart button that is attached to the `hr_appraisal` model will not detect that there is an event.

Solution:
	Don't accept a `res_id` which is zero. If so, take the default `res_id` and update it in the dictionnary that will be used to create the event.

opw-3042573

closes odoo/odoo#104627

Related: odoo/enterprise#33510
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Ubuntu Jammy brings some breaking changes for odoo 14.0. This PR aims to ensure compatibility if deployed on ubuntu Jammy. This PR is mainly a backport of #88803

Main changes
===========

* support for python 3.10
* werkzeug 2.0+, including vendoring werkzeug's user agent parser in odoo/tools/_vendor/useragents.py (= the one from version 0.16) as it is discontinued after v2.1
* currentThread is now deprecated (use current_thread instead)
* default requirement version (based on deb package version)
* new opcode in python 3.10
* distutils.version.LooseVersion is deprecated

wkhtmltopdf
----------------
wkhtmltopdf version packaged with ubuntu jammy doesn't have patched qt but will work without headers and footers. Suggested wkhtmltopdf version 0.12.5 doesn't have a build working with jammy yet because of incompatible libssl dependencies. A working version can be found on nightly server.

As usual, all changes are made with the spirit to keep compatibility with previous version (Focal)

enterprise PR: odoo/enterprise#30412

closes odoo/odoo#98081

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

The future removal of these deprecated methods or module are properly
handled in upper versions.

Part-of: odoo/odoo#98081

Werkzeug 2.0 redirect method expects a string.

Part-of: odoo/odoo#98081

When importing reportlab from python 3.10, a deprecation warning is
emitted from the standard library importlib module.  This warnings
occurs because of the usage of the `load_module()` method used in
reportlab. This deprecated usage is not yet fixed in the current
reportlab version 3.6.11.

This makes it difficult to filter out with the `filterwarnings` method
because it would then catch any other usage of `load_module` from
anywhere.

With this commit, this deprecation is caught and ignored at the import
time.

Note: this issue did not appear in 15.0 because `reportlab` is imported
in the `odoo.tools` module which is loaded before activation of the
deprecation warnings.

Part-of: odoo/odoo#98081

Also, define `Event` attribute in `__init__` where it belongs.

Part-of: odoo/odoo#98081

Before werkzeug 2.0, the `path` attribute was a cached property, now
it's a regular attribute.

With this commit, both cases are handled.

Part-of: odoo/odoo#98081

Part-of: odoo/odoo#98081

Part-of: odoo/odoo#98081

As werkzeug.utils.unescape is deprecated in werkzeug 2.0 and the
markupsafe version of unescape just uses the built-in html.unescape [0],
we can use directly the same built-in method.

[0]  pallets/markupsafe@c35603a

Part-of: odoo/odoo#98081

lxml 4.6.1 has issues with python 3.10. So we can safely mimic 15.0 as
it's Focal based too.

Error encountered while importing etree from lxml:
etree.cpython-310-x86_64-linux-gnu.so: undefined symbol: _PyGen_Send

Part-of: odoo/odoo#98081

Part-of: odoo/odoo#98081

As the werkzeug.utils.escape method is deprecated in werkzeug 2.0, we
vendor it in order to ensure compatibility in stable.

This may be be replaced by markupsafe in master as stated in the warning.

Part-of: odoo/odoo#98081

Since Python 3.10, the invalid escape sequence warning use quotes to
display the invalid sequence. Because of that, the filter does not catch
it anymore.

With this commit, they are caught in all supported versions.

Part-of: odoo/odoo#98081

As of werkzeug 2.0, the `posixemulation` compatibility layer for atomic
rename operations is abandoned[1]. In the mean time an atomic,
cross-platform file renaming function was introduced in the stdlib, as of
Python 3.3: `os.replace()`.

By using `os.replace()` instead of `posixemulation.rename()`, we can
ensure compatibility with versions 0.x, 1.x and 2.x of werkzeug.

We've always required Python 3.5+ since the P3 support, so
`os.replace()` is always available.

This is a follow-up of the work for supporting werkzeug 1.x [2]

References:
[1] https://github.com/pallets/werkzeug/pull/1790
[2] vendoring of werkzeug.sessions: odoo/odoo#45931

Part-of: odoo/odoo#98081

blocked to their stock inventory records

closes odoo/odoo#100773

X-original-commit: cd1a85ae
Signed-off-by: Laurent Smet <las@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#105136

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

closes odoo/odoo#104164

Signed-off-by: Carmen Bianca Bakker <carmen@coopiteasy.be>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>