For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description. This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent. Steps to reproduce (in

For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description.

This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent.

Steps to reproduce (in 18.0):

- Open website module
- Go to /slides
- Add a carousel snippet to the side panel > Save
- Traceback

[1]: https://github.com/odoo/odoo/commit/0cd42f8b55e2ab8f214653556b5bde4b54281972

opw-4272357

Forward-Port-Of: odoo/odoo#195777

**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline

**Problem**:
When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example,
`a<u>b</u>c` → `a<u><font>b</font></u>c`,
which results in an inconsistent appearance.

**Solution**:
Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling.

**Steps to Reproduce**:
1. Add text.
2. Apply underline.
3. Increase font size.
4. Observe that the underline remains the original size instead of scaling with the text.

opw-3086072

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

Forward-Port-Of: odoo/odoo#195569

**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe

**Problem**:
The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`.

**Solution**:
Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds.

**Steps to reproduce**:
1. Open an email marketing template.
2. Extend the "Centered Logo" snippet to the maximum size (`col-12`).
3. Observe a traceback error.

opw-4381159

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

Forward-Port-Of: odoo/odoo#193255

…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:

…sively

The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled.

Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'.

task-id: 4531511

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

Forward-Port-Of: odoo/odoo#196074
Forward-Port-Of: odoo/odoo#195814

A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s

A sales team should be assigned only to sales type moves (invoices,
credit notes, ...). Currently, it is possible that some Bills get a
sales team assigned. This is not ok as it will distort the reports
if users analyze by sales team.

It occurs when `_compute_team_id` is called on a recordset containing
sales moves and other moves.
Even if sales moves are correctly filtered a `self.concat` is used to
set the `team_id` and it will return the concatenation of `self` with
the arguments, so also the non sales moves will have the team assigned

opw-4422292

Forward-Port-Of: odoo/odoo#195852
Forward-Port-Of: odoo/odoo#195645

A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154

A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable.

This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents.

task-4364446

Forward-Port-Of: odoo/odoo#196187
Forward-Port-Of: odoo/odoo#196154

### Description of the issue/feature this PR addresses: - Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided. ### Desired behavior after PR is merged: - The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`. task-3829323

### Description of the issue/feature this PR addresses:

- Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided.

### Desired behavior after PR is merged:

- The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`.

task-3829323

Forward-Port-Of: odoo/odoo#194365

Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003 Forward-Port-Of: odoo/odoo#194804

Change questionable emails for 2 users.

Make new demo CV for them as well because we only had the
binary pdfs.
Raw latex can be found at (google drive):
* https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link
* https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link

task-4507003

Forward-Port-Of: odoo/odoo#194804

Before this commit: Steps 1) Create 3 statement lines in bank journal 2) Cancel the journal entry of the middle one 3) Try to add the first and third lines to a statement => It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line. After this commit: This operation can be performed as the missing line

Before this commit:
Steps
1) Create 3 statement lines in bank journal
2) Cancel the journal entry of the middle one
3) Try to add the first and third lines to a statement

=> It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line.

After this commit:
This operation can be performed as the missing line is canceled, and it shouldn’t be counted for the contiguity check. Also, it should be considered in the statement assignment, similar to how the statement button works in the widget/kanban view.

Recording of reproducing the issue: 
https://drive.google.com/file/d/1I5xwNie1HL9ifuK0z21a6yWDdqI_xbTU/view?usp=sharing 

Discussion with OLMA: https://discord.com/channels/678381219515465750/1099994955830796348/1330856829638545429

opw-4385040

Forward-Port-Of: odoo/odoo#194541

**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; - Update the product's `Quantity` to 1 at least; *The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.* - Update the field `Quantity` of components to: - **C1**: 1 unit - **C2**: 3 units -

**Steps to reproduce:**
- Create a storable product `P1` with the following BoM:
    - Qty: 1 unit
    - Components:
        - C1, C2, C3: 3 units
- Create a MO to produce one unit of `P1`;
  - Confirm the order;
  - Update the product's `Quantity` to 1 at least;
    *The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.*
- Update the field `Quantity` of components to:
    - **C1**: 1 unit
    - **C2**: 3 units
    - **C3**: 4 units

___
**Issue:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less than the <ins>total needed</ins> value &rarr; highlights in green;
- **C2**: equal to the value &rarr; highlights in black;
- **C3**: higher than the value &rarr; highlights in orange.

![Capture d’écran 2024-12-30 à 17 49 56](https://github.com/user-attachments/assets/e4fe7488-de04-4749-9930-85f11f71532a)

___
**Expected:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less -> black;
- **C2**: equal -> green;
- **C3**: higher -> orange.

___
**Cause:**
Text decorations are based on a wrong logic by getting the quantities from wrong field. This field has been changed during an apocalypse.
https://github.com/odoo/odoo/blob/c43297435cfcaf560d5c952ac3c4a383a6f1dc28/addons/mrp/views/mrp_production_views.xml#L405-L406

___
**Fix:**
Reset good field to check quantities, inspired by Odoo 16 using the computed `should_consume_qty` value to check the consumption status:
https://github.com/odoo/odoo/blob/67c78b38e794333eae55758ad4610515df5c49d2/addons/mrp/views/mrp_production_views.xml#L342-L343

![Capture d’écran 2024-12-30 à 17 49 26](https://github.com/user-attachments/assets/f30bd7fc-0140-4c16-abaf-540f4c1bc12d)

___
**Forward:**
To forward up to master.
Odoo 17 :
```
<field name="quantity" string="Quantity"
    decoration-success="product_uom_qty - quantity &gt; -0.0001 and product_uom_qty - quantity &lt; 0.0001"
    decoration-warning="quantity - product_uom_qty &gt; 0.0001"

```

___
opw-4393156
opw-4391582
opw-4391600

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

Forward-Port-Of: odoo/odoo#190162

- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill

- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2.

- Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice.

In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order.

Similarly:

- Create a vendor bill with **Product B**, with a cost of 1000 and a quantity of 2.

- Add a line with **Product B**, with the same cost but a quantity of -1.

In the product margin report, the `total_cost` for **Product B** is shown as 3000, even though we only bought for 1000.

In `_compute_product_margin_fields_values`, the SQL query takes the absolute value of the balance of every account move line to compute `total`. This means negative values become positive and are added to the positive values instead of canceling each other out, creating the above issues. As a result, the product margin report does not align with the balance sheet.

The absolute value is used because `total` is used to compute statistics related to both `out_invoice` (e.g., turnover) and `in_invoice` (e.g., total cost), which both need to be positive. However, the same result can be achieved by inverting the sign for `out_invoice`.

opw-4342691



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

Forward-Port-Of: odoo/odoo#193440

In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#190938

In this PR,
- Set the default department for the Plans smart button.
- If there is no plan, it will open the form view.

Task-4356557

Forward-Port-Of: odoo/odoo#190938

Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko)

Steps to reproduce
==================

- Activate the assets debug mode
- Print a report => The footer is missing

Cause of the issue
==================

The sames fonts are used in the header and footer.

A first request is made


```http
GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1
Accept: */*
Cookie: REDACTED
Connection: Keep-Alive
Accept-Encoding: gzip
Accept-Language: en-US,*
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34

HTTP/1.0 200 OK
Server: Werkzeug/2.0.2 Python/3.11.11
Etag: "1710849406-32964-706485214"
Expires: Tue, 28 Jan 2025 13:18:36 GMT
Content-Disposition: inline; filename=Lato-Bla-webfont.woff
Content-Type: application/font-woff
Date: Tue, 28 Jan 2025 13:18:36 GMT
Last-Modified: Tue, 19 Mar 2024 11:56:46 GMT
Content-Length: 32964
Cache-Control: no-cache, max-age=0
Accept-Ranges: bytes
```

The second request from the footer is

```http
GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
If-Modified-Since: Tue, 19 Mar 2024 11:56:46 GMT
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34
Cookie: REDACTED
Connection: Keep-Alive
Accept-Encoding: gzip
If-None-Match: "1710849406-32964-706485214"
Accept: */*
Accept-Language: en-US,*

HTTP/1.0 304 NOT MODIFIED
Server: Werkzeug/2.0.2 Python/3.11.11
Date: Tue, 28 Jan 2025 13:18:36 GMT
Accept-Ranges: bytes
Content-Disposition: inline; filename=Lato-Bla-webfont.woff
Cache-Control: no-cache, max-age=0
Expires: Tue, 28 Jan 2025 13:18:36 GMT
Etag: "1710849406-32964-706485214"
```
When running wkhtmltopdf manually, we obtain the following output:

```
Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager.
This might be an indication of an iframe taking too long to load.
```

This indicates that wkhtmltopdf is not handling the cache headers
correctly and fails to recognize the fact that it should reuse the
previously received version of the file.

Solution
========

In production, odoo should run behind a reverse proxy that handles
static files, and the debug assets mode should not be used.

Nevertheless, since wkhtmltopdf misinterprets cache headers, we simply
remove them in case

opw-4413445

Forward-Port-Of: odoo/odoo#195826

This update improves internal test reliability for Belgian payroll accounting by enabling real-time communication support during automated checks. It helps ensure payroll accounting features are validated more consistently before release, with no direct change for end users.

task-3970199