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>

We made the field cumulated balance non exportable
in the GL.

Steps:

- Go to Accounting->Accounting->General Ledger
- Unfold and select one or several lines
- export lines
-> The cumulated balance is not computed

The reason is we don't pass in the compute as we don't
come from the search_read method when exporting, so we don't have a domain
to compute the cumulated balance.
As we can't force the domain, we override the fields_get method
to make the field non exportable.

opw-2800669

closes odoo/odoo#91527

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

closes odoo/odoo#104891

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

This commit fixes premature usage of `purchase_price` field on
sale.order.line model, before its definition in sale_margin module.

Since this test requires both sale_mrp and sale_stock_margin to pass,
this commit adds an auto-install bridge module that solely address this
issue.

Steps to reproduce:
- Install sale_mrp module
- Run tests (at least .test_kit_cost_calculation)

Problem:
Traceback:
AttributeError: 'sale.order.line' object has no attribute 'purchase_price'

See odoo/odoo#100126

Part-of: odoo/odoo#104891

closes odoo/odoo#104402

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

closes odoo/odoo#104076

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

### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new  account of type
  `Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
  * Tax type: Purchases
  * Tax computation: Percentage of Price
  * Amount: 22%
  * Distribution of invoices:
    * add a line with the following parameters:
      % = 40, Based On = 'of tax' and Account = the tax paid account.
    * add a second line with the following parameters:
      %= 60, Based On = 'of tax'
  * Distribution of Credit Notes: Add the same lines as
    'Distribution of invoices'
  * In the Advanced Options tab, set :
    * Tax Eligibility = 'Based on Payment'
    * Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set
  Taxes = `T` on that line
* confirm and register payment

Now go to Accounting > Journal Items, group by Journal. Look through the
'Cash Basis Taxes' group and find the entries related to the vendor bill
you just made. One of the debit lines on account `A` is not correct.
Here, the account should be the one specified on the invoice line.

opw-2796727

closes odoo/odoo#103631

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

This commit is to compute correct lot number for serial/lot tracked
products on refund invoices

Reproduction:
1. Install Sale, Accounting, Inventor. In setting of Inventory, enable
Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices,
Display Lots & Serial Numbers on Delivery Slips.
2. Create a product with lot/serial number
3. Create a order of this product, confirm. Click the delivery and
validate it.
4. Back to the SO, create an invoice, confirm and print it, the serial
number shows.
5. At the invoice, click “Add credit note”, choose “Full refund” (2
invoices for the SO) or “Full refund and new draft invoice” (3 invoices
for the SO), the lot number doesn’t show in new draft invoice or the
refund invoice

Reason: the current lot number tracking workflow focused on invoicing
different numbers of products and making sure it gets the correct
lot/serial number. It doesn’t include the refund invoice case.

Fix: since the current working logic works great with invoicing products
which are delivered from the warehouse to the customer, we can reuse
this logic for refund invoices for products which are returned from the
customer to the warehouse. In the refund and return case, we switch the
calculation of warehouse and customer. Thus, a return can be seen as a
delivery from the customer to the warehouse.
In the code, we set a new variable, return_source_usage, to check if the
account move type is a delivery or a return. If it’s an invoice for
return, we take the opposite of the previous invoiced product quantity.
Because in a refund, previous invoiced is now considered as refunded.
In the original workflow, when sml.location_id.usage is “customer”, it’s
a return and we update the returned_qty and the related quantities. In
the new workflow, if the invoice is a refund one, we do the same steps
when sml.location_id.usage is “internal”, e.g. when the stock move line
is a delivery, we consider it a return.

For refund invoices. There are two choices of refunding:
1. refund and a refunding invoice: 2 invoices for the order, one is the
original one, another is the refund
2. refund and create a new draft invoice: 3 invoices for the order,
original one, a new draft one and the refund.

In the second case, we will create a new draft invoice. If we simply
apply the original work logic, the lot number will not be printed on the
draft invoice. This is because the previous amls list includes its
original invoice. We have to filter out the duplication of the same
invoice to print the right lot number for the new draft invoice.

Added the report test for two refund cases, one for cancel (Full refund)
and another for modify (Full refund and new draft invoice)

opw-2879714

closes odoo/odoo#99691

Signed-off-by: Laurent Smet <las@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#105149

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