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>

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

X-original-commit: 5456f198
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

To Reproduce
============

- enable QR code on Accounting settings
- with a customer who has a bank account create a credit note for him/her
- in other info tab, make sure that the qr code method is empty
- send or print the credit note

The Problem
===========

the qr code method field will be filled with SEPA, and a QR code will be added to the PDF

Solution
========

Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden
and no QR code should be generated.

opw-3010649

closes odoo/odoo#104496

Signed-off-by: William André (wan) <wan@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#105150

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

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

closes odoo/odoo#104857

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

Issue :
- When sending an sms reminder by cron user, `_get_display_time` is
used which always uses Odoobot (cron user) timezone regardless of the
partner timezone

Fix:
- use `partner_id.tz` instead of Odoobot

OPW-2991624

closes odoo/odoo#100733

Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

Steps to reproduce:
1-set language to an LTR language (arabic / hebrew...)
2-select any field with the date-time range widget (eg: planning>add)
3-the hour and the minute selection is reversed.

Bug:
the hours and minutes order depends on the language orientation where
they should always follow this format HH:MM

Fix:
force the time to be displayed Left To Right regardless of language

opw-2953221

closes odoo/odoo#100320

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

The wizard would update the amount and payment_difference in multiple
cases as the fields get updated by the user.
In multicurrency, the base amount would be converted to the selected
currency at the date of the payment selected by the user.
If the date is emptied before changing the currency, this would lead
to a traceback when calculating this amount.

In order to fix that, we can fall back on today as date to convert
the amount, which will avoid a traceback and won't impact the result
since the amounts will be updated again when the required date field
is filled.

Fixes https://github.com/odoo/odoo/issues/92114



closes odoo/odoo#105113

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

Steps to reproduce:

  - In odoo, create an event "example" in the future with alice@outlook.com and add
    bob@outlook.com to the attendees
  - In the bob outlook account, there should be an ics file with the
    following email "Invitation to example"
  - Drag and drop the ics file into outlook calendar
  -> Bob is set as the organizer

Cause of the issue:

  The organizer property is missing from the ics file
  cf https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1



opw-2841276

closes odoo/odoo#100426

Signed-off-by: Arnaud Joset <arj@odoo.com>

Those tags should only be created by the tax reports; creating them manually makes no sense.

closes odoo/odoo#105005

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