### Steps to Reproduce
1. Activate any other language (ex. FR)
2. Create a new Discount code in Discount & Loyalty
3. Change your user language preference to FR, open the newly created loyalty reward, and change the Description on Order to Test Discount for both languages
4. Navigate to the backend Product Variants menu and observe how its name did not translate in English

### Description of the issue/feature this PR addresses:
**Issue:** When you edit a translation for a loyalty.reward description in a multi-language setup, the product name (`discount_line_product_id.name`) fails to receive the complete translation in all languages. It only updates the current language.

**Solution:**
Override the 'update_field_translations' method on the loyalty.reward model. When changes are saved for the 'description' field on the discount code, intercept the payload and mirror directly at the discount product's `name` field.

### Current behavior before PR:
Updating the reward description only updates the current language and all other languages do not change.

### Desired behavior after PR is merged:
For all languages in which changes are made in a discount code's description, the discount line product name will reflect the same changes. 

opw-6314760

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

Forward-Port-Of: odoo/odoo#271680

Currently, an error occurs when a user previews a canceled subscription order.

**Steps to Reproduce:**
 - Install `sale_subscription` module.
 - Go to `Subscriptions` and create a `subscription order` with:
    - a `subscription product`,
    - a `recurring plan`,
    - an `Until` (end date) value.
 - `Cancel` the subscription order.
 - Click `Preview`.

`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

When previewing a subscription order, the portal view is rendered. During rendering, the 
subscription portal template is used, which computes tax values and requires calculating the 
next invoice date based on the recurring plan's billing period. However, for canceled 
subscription orders, next_invoice_date is False because it is only set when the order is in 
the sale state. As a result, an error is raised [2].

This commit ensures that only subscription orders in the sale state use the subscription 
portal template. Canceled subscription orders use the default sale order preview, similar 
to orders in the draft and sent states. This is appropriate because canceled subscriptions 
are not correctly displayed in the subscription portal, and they should not attempt to 
render the subscription-specific portal view.

[1]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/controllers/portal.py#L686-L687

[2]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/models/sale_order.py#L2172-L2175

sentry-7579114635

When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is shown in the discount popup as 8.33% and, when confirmed without editing, applies a 100% discount on the order instead of 8,33%.

Steps to reproduce:
-------------------
* Activate Belgian localization for accounting
* Set the user language to Dutch (Netherlands) or Dutch (Belgium)
* In Point of Sale settings, enable global discounts and set the default discount percentage to 8,33%
* Open a POS session, add a product to the cart, and click Discount
* Confirm the popup without changing the value

> Observation:
The popup displays 8.33% (with a dot). After confirmation, the order receives a full discount instead of 8,33%.

Why the fix:
------------
The discount popup initialized its value with `String(discount_pc)`, which always uses a dot as decimal separator. POS then parses the input with locale-aware rules where `.` is the thousands separator, so "8.33" is read as 833 and capped to 100%. Format the default discount percentage with `formatFloat` so the popup starts with the correct localized value (e.g. "8,33").

opw-6334367

Forward-Port-Of: odoo/odoo#273022

**Issue 1:**

Step to reproduce:
- Type ':wave' to open suggestion list
- Now click on any emoji from the suggestion list

Description of the issue:
- The selected emoji gets inserted, but the `searchNode` `:wave` does not get removed and remains beside the inserted emoji

Cause:
- When the user clicks an emoji from the suggestion list, focus shifts to the suggestion list item. As a result, `selection.extend()` is unable to properly select the searchNode in the editable area. Because the `searchNode` is not selected, `deleteSelection()` fails to remove it before inserting the emoji.

Solution:
- Added the `user-select-none` class to the suggestion list to prevent selection/focus shift on emoji click, ensuring the searchNode is properly selected and replaced by the selected emoji


**Issue 2:**

Steps to reproduce:

- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:

- When using the SwiftKey keyboard, pressing Backspace after an emoji can result in an incorrect cursor position.

Cause:
- When Backspace is pressed, a selection snapshot is cached during the `keydown` event.
- Later, `deleteBackward` converts the emoji back to its corresponding expression (:p) by triggering an undo operation, but the cached selection does not get updated. As a result, the previously cached selection is reused, causing the cursor to be placed incorrectly.

Solution:

- After performing the undo, update the cached selection to match the new cursor position.
- This ensures that the latest selection is used instead of the outdated selection captured during `keydown`.

**Issue 3:**

Steps to reproduce:
- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:
- Pressing Backspace on an emoji does not revert it to its matching expression (`:p`).

Cause:
- On mobile devices, `event.key` can be undefined in keydown. As a result, `deleteBackward` is triggered through the `beforeinput` event, which correctly reverts the emoji to its matching expression. However, after that, the `input` event is triggered and converts the expression back into the emoji again, making it appear as if the emoji was not reverted.

Solution:
- When the event type is `deleteContentBackward`, skip converting the expression back into an emoji and return early.


task-6201173

Forward-Port-Of: odoo/odoo#263777

### Issue:
In 19.0, the values of lines 415 and 420 in the Swiss tax report are negative, causing line 479 to add them instead of subtracting

Line 479 formula:
`tax_ch_400 + tax_ch_405 + tax_ch_410 - tax_ch_415 - tax_ch_420`
For the subtraction to be correct, 415 and 420 must be positive

### Cause:
In 18.0, each tax grid had two variants (`+415`/`-415`) allowing the user to control the sign manually
The double negative (`-*-`) incidentally produced positive values in the report

In 19.0, the unified tax grid merges them into a single tax grid (`415`) with automatic sign handling
415 and 420 are correction lines that must appear positive in the report so that 479 subtracts them correctly
The formulas were not updated to reflect this change

### Steps to reproduce:
- Install `l10n_ch_reports` and `accountant`
- Switch to `CH Company`
- Create and confirm a Bill (Amount: 100, Tax: 8.1%)
- Create and post a Journal Entry:
  - Account: 1170 Input Tax (VAT), Credit: 2, Tax Grids: 415 and 420
  - Account: 1021 Bank, Debit: 2
- Open the Tax Report for this month
 
Before the fix, lines 415 and 420 are negative and line 479 adds them instead of subtracting

opw-6311126

Forward-Port-Of: odoo/odoo#272385

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

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#272324
Forward-Port-Of: odoo/odoo#271864

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122352
Forward-Port-Of: odoo/enterprise#122035

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

### Issue:

Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.

### Concrete Issue 1:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2

### Concrete Issues 2 and 3:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
    - 1 units of LOT001 in Shelf1
    - 2 units of LOT001 in Shelf2
    - 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.

### Cause of the issue:

The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.

### Behavior after the fix:

Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.

If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.

If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.

### Additional note on the fix:

Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.

### Note:

The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.


opw-6173914
opw-5881661

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

Forward-Port-Of: odoo/odoo#272253
Forward-Port-Of: odoo/odoo#263037

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/6b67a45b-6e52-4e02-a827-1aca5d8417ec" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/077bc3ab-bc6e-42a1-85e6-adf778000b92" />

After the fix:
-----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/da2a43e3-01c0-44c5-b529-e73f21825150" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/b658b95f-5bc3-4b7a-9e7c-8b182cab48a0" />


opw-6131231

Forward-Port-Of: odoo/odoo#269716

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

## Problem
When multiple Default Prompts are configured for the same AI Agent and
interface key, clicking the "Ask AI" button raises a ValueError.

## Cause
The `_get_composer_from_key_and_model` method searches for composers matching
an interface_key and model, but doesn't limit the results. When multiple
Default Prompts exist for the same agent, the search returns multiple records,
causing a singleton error when accessing `ai_agent_id`.

## Steps to Reproduce

[[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)]
1. Go to AI > Configuration > Default Prompts
2. Create a new Default Prompt with Odoo Agent
3. Click the Ask AI button in the top-right corner
4. Error: ValueError: Expected singleton: ai.agent(2, 1)



## Fix

Replace the two-step search with a single search using an `OR` domain:

- Search both model-specific and generic Default Prompts in one query.
- Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones.
- Return only one record using `limit=1`.

This preserves the previous behavior while preventing singleton errors.

---
opw-6323764

**Steps to reproduce:**
* Install the **account_peppol** and **l10n_be** module.
* Switch to BE Company.
* Create and confirm a BE customer invoice.
* Open the "Send & Print" dialog.
* Activate Peppol (register as a Peppol participant) in developer mode and demo mode by clicking on `Why should you use it ?` on the banner in wizard.

**Observed behavior:**
* An Uncaught Promise OwlError trace is thrown on the screen: `TypeError: Cannot use 'in' operator to search for 'toString' in null`.
* The success notification indicating that Peppol was activated fails to appear.

**Cause:**
* Upon successful registration, the `peppol.registration` wizard triggers a client action to display a success notification via `display_notification`.
* The backend Python code explicitly passed `title=None` in the notification parameters, which is serialized to `null` in the JavaScript frontend.
* In previous versions (like 19.2), the `Notification` component's `title` prop validation was defined loosely as `{ type: [String, Boolean, { toString: Function }] }`. OWL did not strictly validate this shape, allowing `null` to pass through without error.
* In 19.3, the prop validation was updated to strictly enforce the object shape: `{ type: [String, Boolean, { type: Object, shape: { toString: Function } }] }`. Because JavaScript evaluates `typeof null` as `"object"`, the OWL validation schema now attempts to verify the shape by evaluating `'toString' in null`. Using the `in` operator on `null` is illegal in JavaScript and immediately crashes the application.

**Fix:**
* Replace `title=None` with `title=False` in the `_action_send_notification` method.
* This translates to `false` in the JavaScript frontend, which seamlessly satisfies the `Boolean` prop type validation for the OWL component and allows the notification to render safely without errors.

opw-6333224

The previous memory profiler was causing a lot of performance issues.
This is because tracemalloc tracks the allocations that happens at the
python interpreter level by attaching to the cpython allocators. This
first meant each allocation that happens through python has to go
through a callstack while holding the GIL and preventing the thread and
other threads from operating. This callstack does multiple things,
first is walking the allocation back from the current frame up until
the specified frame depth at the start of collection. The other is
updating the internal object that keeps track of the allocations and
what cause them up until now which degrades the performance even more
when the allocator keeps running for a long time. Increasing the frame
depth also means the partitioning becomes even more fragmented in the
internal object and leads to higher memory usage. This in turns means
lower performance as well. The issue becomes more evident when the
overhead of tracemalloc blocks any execution even turning it off
because the gil cannot be released until the full allocation execution
happens.

Currently this would happen on long enough requests or a high enough
depth.

Two PRs were made to try to address this issue.

1- https://github.com/odoo/odoo/pull/251950 : This PR tries the
solution of having a lower frame depth but matching the frames based on
a window of frames so that we can reconstruct an approximation of the
flamegraph, for example: matching window of 2 frames
1 - > 2 - > 3 - > 4
2 - > 3 - > 4 - > 5
would mean that we would match frames 2 and 3 in both stack traces and
append the first frame to the second callstack which would look like
1 - > 2 - > 3 - > 4 - > 5
Neverthless this was deemed to have too big of an assumption in the
building heuristic.

2- https://github.com/odoo/odoo/pull/253120: This PR was supposed to be
introducing memray as a profiler. Memray is the best tool for this
usecase. First because it attaches on the native system allocation
calls, and uses a file to append to on allocations. This solves both of
the issues that we had in the beginning but the issue with memray is
that it's an external tool that was deemed unnecessary to add.

The final solution is this PR:
The PR assumes a heuristic that in worker mode, a single worker handles
one thread which mean that the process memory can be fully attributed
to the request. The heuristic is also based that on a high enough
sampling rate, the delta can be fully attributed to the current frame.
This is a close enough approximation to know where to look but not what
is the actual memory usage by line.

Forward-Port-Of: odoo/odoo#273158
Forward-Port-Of: odoo/odoo#253604

### Steps to reproduce:

- In the settings Enable: Multi-steps Routes, Packages
- Put your warehouse in delivery in 2-steps
- On the Pick operation type in the barcode tab disable: "Allow extra products"
- Create two storable products P1 and P2
- On P2 > On hand > Update Quantity > New
- Create a new line in WH/Output with a package POOK for 1 unit
- Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output
- Set the quantity of the move to 1 unit and go to the barcode app
- Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK
#### > An error is raised: This package contains extra products and extra products are not allowed on this operation.
#### Expected behavior:
The package should be set as result package.

### Cause of the issue:

In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed:
https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035
Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway.

opw-6303969

Forward-Port-Of: odoo/enterprise#121789

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

Forward-Port-Of: odoo/enterprise#122308

[[REF] mail: consolidate attachment Content-Type normalization](https://github.com/odoo/odoo/pull/273097/changes/ad4e34c5c79450b1e976d9ba7047487218690585)

Two separate spots handled malformed Content-Type headers. Merge them
into one block, read the raw header once with partition(';') to have
both the type and its parameters available without re-fetching the
header for each case.

No behavior change.

[[FIX] mail: handle attachment Content-Type with no subtype](https://github.com/odoo/odoo/pull/273097/changes/7b410fbe606b7e476f0005485e42783834983b75)

Some mailers send attachments with a bare token as Content-Type instead
of a valid 'type/subtype' pair, e.g.:

    Content-Type: base64; name="foo.pdf"
    Content-Transfer-Encoding: base64

Python's email library normalises any MIME type without a '/' to
'text/plain'. get_content() then decodes the base64 payload as UTF-8
text, replacing invalid byte sequences with U+FFFD. The subsequent
encode('utf-8') bakes those replacements in, permanently corrupting
the stored file.

Per Postel's law [RFC 761], be liberal in what we accept: detect these
non-standard types via `not all(mimetype.partition('/'))` and fall back
to application/octet-stream, keeping the original parameters (filename,
charset, etc.) so the attachment is stored intact.

opw-6227526

Forward-Port-Of: odoo/odoo#273097

Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
   - Apply To: Category
   - Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.

Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.

Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.

This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.

Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.

opw-6346422

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813