Currently, an error occurs when the user follows the below steps and tries to
run cron "Maintenance: generate preventive maintenance requests"

Steps:
- Open maintenance > Configuration > Maintenence Teams
- Create new team e.g. "ABC"
- Go to Equipments and create new equipemnt
- Set 1 "Preventive Maintenance Frequency" from maintenance page
- Select "ABC" in Maintenance Team >> save it
- Delete  Maintenence Team "ABC"

This commit solves the above issue by restricting the deletion
of maintenance teams who are related to equipment.

sentry-4467657509

closes odoo/odoo#135780

Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

closes odoo/odoo#137603

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

Part-of: odoo/odoo#137603

Part-of: odoo/odoo#137603

Part-of: odoo/odoo#137603

Part-of: odoo/odoo#137603

Part-of: odoo/odoo#137603

Part-of: odoo/odoo#137603

This commit https://github.com/odoo/odoo/commit/a9980477048e4adffda4a71a72ff1cc8490637f9

 wrongly impeached to generate a SEPA QR-code on the invoice when l10n_ch was installed and the company and customer were in Switzerland. This was too restrictive, and broke the previous behavior, which allowed manually enabling the SEPA QR invoice by invoice if necessary. We restore the old behavior with this commit.

OPW 3516380

closes odoo/odoo#137293

Signed-off-by: Cedric Snauwaert <csn@odoo.com>

[14.0][IMP] flag ocb environment

When making backports we could need to address double compatibility. We
can ease it setting a handy flag we can use in our code

TT45385

Step to reproduce:

  - Install `Elearning` module
  - Go to any course and a content as document
  - Upload a pdf with more than 1 page
  - Go to the website and click on the course then on the content with
    the document
  - Go to last page and click on next button (should display suggested
    slides page)
  - Click on previous button

Issue:

  Page displayed is not the last one, but the one before.

Cause:

  When clicking on the previous button, the current page is still the
  last page (just with the suggested slides page on top of it as
  overlay), and therefore will decrease it to the page number before
  last page (nb last page - 1).

Solution:

  When clicking on previous button, if we are on the suggested slides
  page (by checking if overlay is not hidden since no attribute is set
  on `EmbeddedViewer` to know if we are on that page), hide it.

opw-3482712

closes odoo/odoo#135326

Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Steps to reproduce:
- Set up an Italian language company with Italian localisation.
- Set up an English language customer.
- Set up an Italian language supplier.
- Set up a product with dropshipping options.
- Set up a sales order for the product to be dropshipped direct
 from the Italian supplier to the English customer.
- Print the DDT report.

Bug:
The report will be printed in Italian.

Fix:
same as delivery slip reuse _get_report_lang

opw-3526633

closes odoo/odoo#137555

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

Add the possibility to dynamically change the logger level of Odoo and
per IoT handler (drivers and interfaces).
This will be done through the "Handler List" page.

This will be useful to troubleshoot purposes.
In particular when it happens on a specific handler.

The level set should persist on shutdown as saved in Odoo's configuration
using the `--log-handler` parameter, see:
https://www.odoo.com/documentation/16.0/developer/reference/cli.html#cmdoption-odoo-bin-log-handler



Notes:
 - When changing Odoo's level, `werkzeug` logger will change to the same
 level automatically (except in `debug` on which `werkzeug` will be set
 to `info`)
 - `--log-level` Odoo config wasn't used as it has unintended side
 effects when dynamically switching to this level
 - `load_iot_handlers` was modified as otherwise the loggers `__name__`
 could be wrong and inconsistent on which several logger for a handler
 exists. For example: `PrinterInterface.py` and
 `odoo.addons.hw_drivers.iot_handlers.interfaces.PrinterInterface`. In
 this situation `_logger` can be different from one used in the class.
 In addition, of that, the parent logger for the different loggers could
 be different (root and Odoo generally)

opw-3493585

closes odoo/odoo#134174

Signed-off-by: Loan Sens (lse) <lse@odoo.com>

To avoid having to many IEPS taxes, set the sales one as inactive.

task-3100679

closes odoo/odoo#136913

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

[14.0][FIX] purchase_stock: Use hook method

Steps to reproduce:
- Create a component C (automated/FIFO)
- Create and confirm two PO for C
    qty: 1, price: 10
    qty: 1, price: 20
- Make an MO with C as a component
- Unbuild that MO

Bug:
The valuation of the new component C is wrong,
the new move in is valued at the current product cost instead
of its original value.

Fix:
create moves as a return to get the correct value

opw-3379457

closes odoo/odoo#137400

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

Current behaviour:
When creating a nameless contact,
while selecting delivery address type
for an existing company, there is a traceback

Steps to reproduce:
1. Install contacts,sale_management,crm
2. Settings > Sales > Quotations & Orders
3. Check "Customer Addresses"
4. Go to Contacts
5. Create a new contact
6. Check "individual"
7. Select a company
8. Select "Delivery" in Address type
9. Save => traceback

Cause of the issue:
Introduced by https://github.com/odoo/odoo/commit/9ef715fb994564af9e933ba31933a09eca97c24f


partner.name can be False

opw-3495748

closes odoo/odoo#137317

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

- Before fix:
  only select activities done today or in the future so
  it does not reflect the expected behavior of the filter.

- After fix:
  have an expected data with suitable filter name

- OPW: 3504670

closes odoo/odoo#137363

Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>

This uses the hook method introduced in ce1f1b69 for consistency when used on modules
that modify this behavior.

Description of the issue/feature this commit addresses:

As of the first October 2023, some Japanese companies will start using "T" as
country code in their Tax ID. The current vat check only allows the country
code to be used in the Tax ID which means that "T" is refused.

Desired behavior after the commit is merged :

This commit makes it possible for Japanese companies to use "T" as a
country code in their Tax ID.

task-3515786

closes odoo/odoo#136146

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

On update/upgrade we should keep current password policy if its
already set

closes odoo/odoo#137228

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

Fixed the string en passant.

closes odoo/odoo#137142

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>

Decorator 5 changed the default decoration method from a transparent
exec-ing to wrapper functions. This makes the decorators visible to
the profiler, and breaks one of the profiler tests as the stack traces
now differ between using decorator 4 and decorator 5. Amongst other
concerns, this is an issue because debian bookworm has updated
decorator to 5 (.1.1), and the next ubuntu LTS (which should be 24.04
hopefully codenamed Nefarious Nematode) will do the same (Ubuntu has
been providing decorator 5 since 23.04).

5.1 added a `decoratorx` function which corresponds to the old
exec-based `decorator`, however it doesn't have a `decorate`
version. So we have to flag the wrappers, instead of decorate-ing the
original method with them. This seems to have the same semantics so
why we were using `decorate` is not entirely clear why we were not
doing that previously (neither
b1e83fd7 nor #25383 really provide
explanations). Possibly because pylint is a dum-dum and requires
ignoring one of its rules?

Implement in 14 since it doesn't hurt even though the test in question
does not exist yet.

closes odoo/odoo#137096

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

When the user tries to find the 'qty_available' of a product but gives
a string value instead of a float value in domain then the user will face error.

Steps to produce:
- Install `stocks`.
- Create a record rule for model `product.template`. In the domain of record
  rule keep [('qty_available', '<', '10')] as a domain,
  you can give any integral value in the domain but that value should be
  enterred as strings (with quotes).
- Inventory > Products > Products

Error: `TypeError: '<' not supported between instances of 'str' and 'float' `

After applying our commit, if the domain is Invalid then the user will face
`UserError`. There is a function named `_search_product_quantity`  which
initially checks if the domain is valid or not :
https://github.com/odoo/odoo/blob/5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85/addons/stock/models/product.py#L342-L350


It will filter out all the invalid domain and clear search methods.
So now whenever `_search_qty_available` is called first the validity of domain
and operands of the expression will be checked.

sentry-4399815131

closes odoo/odoo#133155

Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

Not very useful to the average user, and can fill up logs during
tests (mostly 16.1 onwards for some reason but might as well square
up everything).

closes odoo/odoo#136944

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

Summary
-------
Currently, floats are not always properly rounded when they are used in
computes or onchanges.

Steps to reproduce
------------------
1. Set Product Price decimal accuracy to 2.
2. Create an invoice.
3. Add a line: quantity 2, price 1.205.
Expected Result: Subtotal of 2.42 (using `2 * round(1.205)`).
Actual Result: Subtotal of 2.41 (using `2 * 1.205`).

Fix
---
Always round floats when they are put in cache.

Partial backport of 4c5cdf5f
opw-3333449

closes odoo/odoo#131906

Related: odoo/enterprise#47980
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

To reproduce
============
- create sms template and apply it to a module different than `res.partner`
for example Tasks
- add context action
- create a task and select a customer that has a phone number
- from action try to send the sms, an error is displayed

Problem
=======
when computing the receipient info, the partner on the record is not taken
into account.

opw-3475456

closes odoo/odoo#134682

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