**Cause:** In version 17.0, new fields (repeat_unit, repeat_type, repeat_until) [ref](https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/maintenance/models/maintenance.py#L265) were introduced in the maintenance module. These fields are set as required in the view 'maintenance.hr_equipment_request_view_form', but they are only visible if the request is a recurrent maintenance request, which causes a validation error when changing the status.

**Solution:** Change the required condition 'True' to recurring_maintenance == True, as the field is only visible for recurring maintenance requests. Making it required for all cases is not feasible.

**Note:** This is not a bug in the general version of 17.0; it is introduced after an upgrade from version 16.0 to 17.0.

for more detail:  odoo/upgrade#6147

**opw-3983692**

**Current behavior before PR:**
 when migrating from 16.0 to 17.0, getting validation error on changing the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/5af78939-933e-41a6-8ab5-f4ba5f69984d)


**Desired behavior after PR is merged:**
able to change the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/e72de3f3-6787-4761-9151-3f7f2fdbd78b)


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#169169

**[IMP] website: match navbar toggler color to overlay header text color**

Before this commit, the navbar hamburger button didn't have the same
color as the text color defined for the "Over The Content" header, which
led to situations where it wasn't visible.

Steps to reproduce:

- Go to the website edit mode.
- Click on the header and choose "Over The Content" for the "Header
Position" option.
- Use the color picker to set the "Text Color" option to white.
- Drag and drop a "Text-Image" snippet onto the page.
- Apply a dark background color to the "Text-Image" snippet.
- Click on the "Mobile Preview" button.
=> The navbar hamburger button is not visible in the header.

After this commit, the navbar hamburger button in the "Over The Content"
header matches the color of the header's text.

task-3853573

---------------------------------
**[FIX] website: hide the overlay on the mobile menu navbar toggler**

Before this commit, after clicking on the mobile menu navbar toggler in
Website edit mode, the blue overlay was covering the button.

This commit fixes this. Indeed, this element is not editable, so there's
no need for an overlay on it.

task-3853573

Forward-Port-Of: odoo/odoo#170423
Forward-Port-Of: odoo/odoo#163139

With restriction imposed by Colombian EDI, the PoS is not 100% compatible and usable as such features are not adapted for such restrictions.

---

Description of the issue this commit addresses:

When trying to issue a credit note via the POS (refund with invoice) and the colombian EDI module is installed, a traceback shows up as it is required to have a description code on the the credit note invoice but nothing in the UI makes it possible to add such data.

---

Steps to reproduce:

1-Install l10n_co_pos and l10n_co_edi
2-Setup all the fun stuff for the edi to work (credentials, VAT, journals, ...) 3-Go in the POS and post an order
4-Now refund that order and make sure to make an invoice with that refund, post 5-An error message shows up to inform that some data is missing.

---

Desired behavior after the commit is merged:

This commit makes it so that when a credit note is created from the PoS, if it is linked to Colombia, the description code is set to 1 if no code is already set.

---

Note on the fix:

It is currently not possible to already have a description code when the invoice is created so the default could be replaced by an assignation but I figured that if we add the possibility in the future, it would be great not to override it.

---

task-3977188

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170867
Forward-Port-Of: odoo/odoo#170739

Steps to reproduce:
- Create a new payment term; "days end of month on the 30"
- create an invoice in may
- set the newly created payment term
- create a invoice line
- save

Issue:
the due date (`maturity_date`) is 2024-06-29

Cause:
Use of `relativedelta` with the singular form of `month` -> absolute value

It was set to 2 so it would always give 29 -> year-02-29

and so  `days_next_month = relativedelta(days=min(int(self.days_next_month), (date_end_of_month + relativedelta(month=2)).day))`

would always return 29 since 29 <= (29, 30, 31)

```
>>> import datetime
>>> from dateutil.relativedelta import relativedelta
>>> date_end_of_month
datetime.datetime(2024, 5, 31, 17, 4, 14, 791820)
>>> (date_end_of_month + relativedelta(month=2))
datetime.datetime(2024, 2, 29, 17, 4, 14, 791820)
>>> min(31, 30, (date_end_of_month + relativedelta(month=2)).day)
29
```

Solution:
use the relative form of `relativedelta`; that is, the plural form `months`
```
>>> (date_end_of_month + relativedelta(months=1))
datetime.datetime(2024, 6, 30, 17, 4, 14, 791820)
```
source: https://dateutil.readthedocs.io/en/stable/relativedelta.html

Note:
Had to change the existing test on the overlapping year since
```
>>> december_date
datetime.datetime(2023, 12, 12, 0, 0)
>>> december_date + datetime.timedelta(days=30)
datetime.datetime(2024, 1, 11, 0, 0)
```
and from date the maturity date would be 31st of January

opw-3916451

Forward-Port-Of: odoo/odoo#169670
Forward-Port-Of: odoo/odoo#166560

### Steps to reproduce:

- Enable Batch Transfers in the settings
- Go to Inventory > Config> Warehouse Management > Operation Types
- On  receipts, enable "Automatic Batches" group by contact
- Create and confirm a purchase order for any contact with:
  - 1 X storable product P1
- Create and confirm a purchase order for the same contact with:
  - 1 X storable product P1
  - 1 x storable product P2
- Go to the assocated stock picking > change the quantity of P1 to 0
- Validate and create a backorder

#### > invalid operation: The following transfers cannot be added to batch

### Cause of the issue:

When the backorder is processed, the stock picking that currently belongs to our batch is validated and a backorder is created: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock/models/stock_move.py#L1891-L1892 The picking associated to this backorder is then added to our batch https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking.py#L160-L162 But for this action to be performed, we need to pass the sanity check verifying that the pickings associated to our batch are allowed: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L282-L286 And here comes the problem, the picking that created the backorder was not yet removed from our batch but is not allowed anymore since it is now in 'done' state:
https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L76-L77

opw-3893543
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#169308
Forward-Port-Of: odoo/odoo#163935

## Pull Request HOOT (PRHOOT) - part 17

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#168328

**Steps to reproduce:**
- Install Accounting, website_sale_subscription and l10n_es_edi_facturae
- Switch to a Spanish company (e.g. ES Company)
- Install a payment provider (e.g. Demo)
- Create a 1-year recurring service product
- Go to the Shop page as a public user
- Add the recurring service to the cart
- Process checkout without entering a VAT number
- Process payment

**Issue:**
An Internal server error is raised while trying to generate Facturae EDI because no VAT has been entered.

**Cause:**
After a transaction is done for a subscription, an invoice is created and sent automatically.
As "l10n_es_edi_facturae" module is installed, it tries to generate the EDI document when sending the invoice, but it fails because the partner has no VAT.

**Solution:**
The Facturae EDI xml is not a mandatory document.
It should not block any flow when not generated manually.
Just ignore any UserError from the generation of Facturae EDI when the invoice has been forced-created.

opw-936227


Linked enterprise PR: https://github.com/odoo/enterprise/pull/65086

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170144

Steps to reproduce the bug:

- Go to the "/partners" page.
- Click on the first partner to go to their page.
- Enter "edit mode".
- Drag and drop a "Dynamic products" snippet into the right column of
the page.
- Save the page.
- Bug: the "Dynamic products" snippet is not visible on the page.

The problem is not specific to the "Dynamic products" snippet. The issue
occurs with all snippets. When the "website description" field is saved,
all HTML attributes are removed (except the "class" attribute). This
causes many bugs, which vary depending on the snippets dropped into the
field.

This commit adds the parameter "sanitize_overridable=True" to the
"website_description" field of "website_partner". It means that the
description can now be properly edited as an user with enough rights,
while keeping the same level of protection for other users editing this
field. Still buggy, below version 15.0, for a restricted editor editing
that description but should be rare.

opw-3908218

Forward-Port-Of: odoo/odoo#165482

Methods from l10n_cl_edi has been moved from l10n_cl_edi (enterprise) as part of https://github.com/odoo/enterprise/pull/46593. This includes
_l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit.

The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here.

As part of the same refactor, methods _l10n_cl_get_invoice_totals_for_report and _l10n_cl_prices_and_taxes had been deprecated, and additionally there is a new exclusive qweb totals widget for chilean invoices. This will allow showing in PDF reports, invoices that had been generated in a foreign currencies or in UF index.

X-original-commit: 7d22eaaf135e20b5c94e8419b8b6418483f1a139

[FIX] l10n_cl: replace t-esc with t-out

(cherry picked from commit 27f592e49b381cf3344b808db8358c677a528489)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#164062
Forward-Port-Of: odoo/odoo#162147

## Issue:
- When purchasing consecutive appointments on the website using eWallet, an error occurs: "It is forbidden to modify a sales order which is not in draft status."

## Steps To Reproduce:
- Create an eWallet program and generate a coupon for the test user.
- On the eCommerce site, navigate to the "Appointments" tab.
- Select a paid appointment and pay using eWallet credit.
- After completing the payment, return to the "Appointments" tab.
- Repeat the same steps to purchase another appointment.
- Encounter the error: "It is forbidden to modify a sales order which is not in draft status."

## Solution:
- In `shop_payment_validate`, when an order is fully paid using a discount or eWallet, the eCommerce website context are not cleared.
- To fix this, call the `sale_reset` method before redirecting to the SO page.

opw-3885533


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170034
Forward-Port-Of: odoo/odoo#167133

PURPOSE

One-click unsubscribe headers are becoming required in order to avoid having
marketing emails being qualified as spam. This change adds those headers
in various modules: digest (backport of changes done for v17), mailing
lists (mail_group module) and improve unsubscribe in mass mailing by supporting
one-click unsubscribe (as current portal page is not one-click available).

Modules
* mass mailing
* digest
* mail group

SUMMARY

To ease the way people can unsubscribe from a digest, we have followed the
advice of RFC8058 by adding the following header to the email:
* List-Unsubscribe: unsubscribe route;
* List-Unsubscribe-Post: List-Unsubscribe=One-Click

The unsubscribe route
* must work with the POST method but not the GET. The GET version is disabled
to avoid unintended unsubscrbe that could be triggered by an anti-spam
accessing the URLs in the headers. Email readers are supposed to do
POST requests as described in the RFC;
* must unsubscribe the user without any additional steps (one click)
* should contain an opaque identifier hard-to-forge to identify the list and
the user (our token fulfills that goal). The goal is to avoid that someone
is allowed to unregister someone else easily.
* must fulfill other conditions like no cookie, no redirection, ... hence those
routes return a 200 status.

MISC

Also fix various issues in digest, notably improve tone down computation and
fix issues when computing the new timespan.

Task-3741195 (Digest: Make It Quality Spam)
Task-3717213 (Mail: Ensure Unsubscribe Headers)
Task-3741203 (Digest: Investigate tone down / reminder)

Forward-Port-Of: odoo/odoo#170825
Forward-Port-Of: odoo/odoo#153864

### Steps to reproduce:

- Create a product SP tracked by lots
- Click on "on hand" and create a lot with 10 units on hand
- Create and validate picking for 1 x any other product
- Unlock the delivery
- Add a line (stock move) for 1 x SP
- Click on the list icon of the line and set your lot
- Save the picking
- Go to the on hand quantity of SP

#### > 1 unit was reserved even though the move is 'done'

### Cause of the issue:

Creating the stock move line associating the lot to the stock move will update the reserved quantity of stock quants independently of the state of the move created:
https://github.com/odoo/odoo/blob/347c7e21002313da155ebf872853078de23b38fe/addons/stock/models/stock_move_line.py#L337-L343 https://github.com/odoo/odoo/blob/347c7e21002313da155ebf872853078de23b38fe/addons/stock/models/stock_move.py#L1525-L1528

opw-3906472
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170561
Forward-Port-Of: odoo/odoo#166186

**Steps to reproduce:**
- Install Accounting, Sales and account_avatax_sale
- Configure AvaTax in Accounting settings
- Create a product with an AvaTax Category (e.g. [D00000000] Digital goods)
- Create a SO:
  * Customer: [US customer] (e.g. Azure Interior)
  * Product: [the created product]
  * Unit Price: [any] (e.g. $ 200.00)
  * Fiscal Position (Other Info tab): Automatic Tax Mapping (AvaTax)
- Confirm the SO => The taxes will be recomputed with AvaTax (e.g.  $ 20.50)
- Create a down payment from SO (via "Create Invoice" button):
  * Create Invoice: Down payment (percentage)
  * Down Payment Amount: 50%

**Issues:**
1) There is no tax on the down payment
2) When confirming the down payment, AvaTax taxes are computed from the Down payment product.
It should not because the Down payment product may have a different AvaTax category than the product on the SO, which may lead to different computed taxes.
The taxes on the down payment should be the same than the ones on the SO.

**Cause:**
1) In "sale_external_tax" module, the "tax_ids" field is removed when preparing the invoice line (in "_prepare_invoice_line" method). Even though "account_avatax_sale" module depends on "sale_external_tax", we want to keep "tax_ids" when using AvaTax.

**Solution:**
1) Create a method checking if taxes should be removed in "sale_external_tax" and override it in "account_avatax_sale" module to keep them.
2) Exclude down payments from external taxes recomputation.

opw-3971513

Forward-Port-Of: odoo/enterprise#64900