### Description of the issue/feature this PR addresses:
International production payments processed via Redsys are failing with error code 9754 (SIS0754). This rejection occurs because the EMV3DS (3D Secure 2.0) payload is sending the billAddrState field with an invalid ISO code format for non-Spanish customers or customers without a state configured.

### Current behavior before PR:
The _redsys_prepare_merchant_parameters method hardcodes the billAddrState key into the DS_MERCHANT_EMV3DS dictionary payload. If self.partner_state_id.code is missing or empty, Odoo sends an empty/falsy value. Because Redsys enforces strict EMV3DS format validation, it rejects the entire transaction for having an invalid state format rather than simply ignoring the empty value.

### Desired behavior after PR is merged:
The DS_MERCHANT_EMV3DS dictionary is now constructed dynamically. The billAddrState key is only appended to the payload if a valid state code actually exists for the partner. RedSys allows this field to be optional, so omitting the key entirely when unavailable causes Redsys to skip the validation for that specific field, allowing certain international payments to process successfully.

opw-6237764

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

Forward-Port-Of: odoo/odoo#274912
Forward-Port-Of: odoo/odoo#270899

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#275119
Forward-Port-Of: odoo/odoo#264039

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

Steps to reproduce
-------------------

- Install sale_project, accountant and project_timesheet_forecast_sale modules;
- Activate analytic accounting in the settings;
- Add an outstanding account to the bank journal’s manual outgoing payment method;
- Create a new billable project;
- Open the top menu, add vendor bills and open it;
- Create a new bill from there, it should use the project’s analytic distribution;
- Confirm it and create a payment;
- Open the payment’s journal entry, it is using the analytic distribution too;

Why is it happening
--------------------

When opening a vendor bill from the project, the project_id is added to the account.move's context to use the correct analytic distribution when we create a  bill.

If we create a payment after accessing the bill from this route, the context is transfered to account.payment.register, and then to the payment's entry lines in the `_create_payments` method.

Due to the `_compute_analytic_distribution` method, the project's distribution is used on the payment's entry.

We propose to filter out payment lines in this compute method.

opw-6329475


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

Forward-Port-Of: odoo/odoo#275076

# How to reproduce
- Create a new product
- Add a reordering rule to that product with :
	- Trigger : Auto
	- Min : > Forecast
- Activate dev mode
- Go to Seetings > Technical > Automation > Scheduled Actions
- Find the "Procurement: run Scheduler" action & run it manually

# The issue
We get a traceback :
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

# Cause
In Odoo, we use an isolation level of "REPEATABLE READ" for transactions :
https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/odoo/sql_db.py#L373

Even with that isolation level psql can throw a `SerializationFailure` if a transaction
attempts to update a row that was modified by another transaction after the isolation
snapshot was taken.

### Example that will raise an error :

Session 1
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
```

Session 2
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
```

Back to Session 1
```SQL
COMMIT;
```

When running our action, we do this :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_rule.py#L697-L703

Which correspond exactly to the first example :
We first update some records with their compute

Then `orderpoints.sudo()._procure_orderpoint_confirm(...)` creates a new
transaction, update some rows & commits :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L716-L719
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L781-L783

Finally, we commit the original transaction with `_commit_progress(1)`

# Proposed solution
Inverse the order of  `_commit_progress(1)` and
`orderpoints.sudo()._procure_orderpoint_confirm(...)` so we commit
the first transaction before starting the second one.

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

Forward-Port-Of: odoo/odoo#268616

Steps
-------
- Configure a fiscalized PoS (Germany, Sweden, or Belgium).
- Open a restaurant PoS session.
- Add a product with a quantity of `4`.
- Decrease the quantity to `2` using the Decrease Quantity popup.

Issue
------
- A traceback is raised when confirming the decrease quantity popup.
- Additionally, the original order line is updated directly instead of
  creating a separate negative line.

Cause
-----
- The serialized order line contains the `id` of the original line, causing the
create operation to overwrite the existing line instead of creating a new one.

Fix
---
- Remove the ID from the serialized values before creating the new order line.

Additional fix
----------------
- When we have a new line with negative quantity, it will never create a new
line on ordering as there was a condition like line's qty - prep quantity is the
quantity diff which is if +ve create new line else update line so in this case
it's like -2 - 0 = -2 which will go to removedline and it's not so how will it update
neither create a new line.

task- 6313732

When opening a table that has no order, `setTable` recycles an existing empty floating order instead of creating a new one (to avoid leaving dangling blank orders behind). The filter only checked for the absence of a table, lines and finalized state, so it could grab any empty floating order, including one deliberately created for takeout or delivery.

Steps to reproduce:
- Open a restaurant POS with presets enabled (e.g. Dine in / Takeaway).
- Cashier A creates a new floating order for a phone customer: selects the Takeaway preset with a future time slot, but has not added any product yet.
- Meanwhile, cashier B opens an empty table from the floor screen.
- => The takeout order is assigned to the table and becomes a dine-in order, losing its takeout context.

Only recycle blank direct sale orders: skip orders that have a floating order name, a scheduled preset time or a preset different from the config default, as those were created on purpose. Tapping a table while on a blank dine-in scratch order still converts it as before.

opw-6041750

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

Forward-Port-Of: odoo/odoo#262573

#### Issue:
When a credit note is renamed so that it sorts before the related invoices,
the lot assigned on invoice previews can become incorrect. Already posted
invoices can appear to consume the first lot again.

Example:
A sale order is delivered in 2 batches: 10 units from SN01, then 10 units
from SN02. Invoice 1 correctly shows SN01 and Invoice 2 correctly shows
SN02. If Invoice 1 is refunded, re-invoiced, and the credit note is then
renamed so it sorts before the invoices, Invoice 2 can incorrectly switch
back to SN01.

#### Steps to reproduce:
- Enable "Display Lots & Serial Numbers on Invoices".
- Create a sale order for 20 units of a tracked product.
- Deliver 10 units from the first lot/serial number and 10 units from a second one in a backorder.
- Create and post 2 invoices, one for each delivery.
- Create and post a credit note for the first invoice.
- Create and post a new invoice for 10 units.
- Reset the credit note to draft, rename it so that it sorts before the invoices, then repost it.
- Check the lot previews on the invoices.

#### Root Cause:
_get_invoiced_lot_values() orders invoice lines with move_name, which is
mutable, then computes the previously invoiced quantities from that order.
When a refund is renamed so it sorts before the invoices, the set of
"previous" invoice lines changes. On top of that, reversed invoices are
filtered out too broadly, even when their reversing move should not yet
impact the current invoice chronology.

#### Fix:
Order invoice lines with immutable move ids instead of move_name, and only
ignore reversed invoices once their reversing move is also before the
current invoice in the effective chronology. This keeps posted invoices
stable while preserving the re-invoice behavior.

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

Forward-Port-Of: odoo/odoo#264776

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#275119
Forward-Port-Of: odoo/odoo#264039

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

Steps to reproduce
-------------------

- Install sale_project, accountant and project_timesheet_forecast_sale modules;
- Activate analytic accounting in the settings;
- Add an outstanding account to the bank journal’s manual outgoing payment method;
- Create a new billable project;
- Open the top menu, add vendor bills and open it;
- Create a new bill from there, it should use the project’s analytic distribution;
- Confirm it and create a payment;
- Open the payment’s journal entry, it is using the analytic distribution too;

Why is it happening
--------------------

When opening a vendor bill from the project, the project_id is added to the account.move's context to use the correct analytic distribution when we create a  bill.

If we create a payment after accessing the bill from this route, the context is transfered to account.payment.register, and then to the payment's entry lines in the `_create_payments` method.

Due to the `_compute_analytic_distribution` method, the project's distribution is used on the payment's entry.

We propose to filter out payment lines in this compute method.

opw-6329475


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

Forward-Port-Of: odoo/odoo#275076

# How to reproduce
- Create a new product
- Add a reordering rule to that product with :
	- Trigger : Auto
	- Min : > Forecast
- Activate dev mode
- Go to Seetings > Technical > Automation > Scheduled Actions
- Find the "Procurement: run Scheduler" action & run it manually

# The issue
We get a traceback :
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

# Cause
In Odoo, we use an isolation level of "REPEATABLE READ" for transactions :
https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/odoo/sql_db.py#L373

Even with that isolation level psql can throw a `SerializationFailure` if a transaction
attempts to update a row that was modified by another transaction after the isolation
snapshot was taken.

### Example that will raise an error :

Session 1
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
```

Session 2
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
```

Back to Session 1
```SQL
COMMIT;
```

When running our action, we do this :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_rule.py#L697-L703

Which correspond exactly to the first example :
We first update some records with their compute

Then `orderpoints.sudo()._procure_orderpoint_confirm(...)` creates a new
transaction, update some rows & commits :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L716-L719
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L781-L783

Finally, we commit the original transaction with `_commit_progress(1)`

# Proposed solution
Inverse the order of  `_commit_progress(1)` and
`orderpoints.sudo()._procure_orderpoint_confirm(...)` so we commit
the first transaction before starting the second one.

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

Forward-Port-Of: odoo/odoo#268616

When opening a table that has no order, `setTable` recycles an existing empty floating order instead of creating a new one (to avoid leaving dangling blank orders behind). The filter only checked for the absence of a table, lines and finalized state, so it could grab any empty floating order, including one deliberately created for takeout or delivery.

Steps to reproduce:
- Open a restaurant POS with presets enabled (e.g. Dine in / Takeaway).
- Cashier A creates a new floating order for a phone customer: selects the Takeaway preset with a future time slot, but has not added any product yet.
- Meanwhile, cashier B opens an empty table from the floor screen.
- => The takeout order is assigned to the table and becomes a dine-in order, losing its takeout context.

Only recycle blank direct sale orders: skip orders that have a floating order name, a scheduled preset time or a preset different from the config default, as those were created on purpose. Tapping a table while on a blank dine-in scratch order still converts it as before.

opw-6041750

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

Forward-Port-Of: odoo/odoo#262573

Description of the issue/feature this PR addresses:
When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`.

In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views.

Current behavior before PR:
A datetime value in the afternoon is grouped under a 12-hour label without AM/PM.

For example, records around `13:50` are displayed under:

    01:00 20 Mar

Similarly, a datetime value around `16:20` may be grouped under:

    04:00 26 Mar

This is ambiguous because the group header does not indicate whether the hour is AM or PM.

Example screenshot showing records around 13:xx grouped under `01:00`:
<img width="310" height="240" alt="image" src="https://github.com/user-attachments/assets/8768f2e8-9aaa-436b-af9f-40055a6032e9" />


Desired behavior after PR is merged:
Hour-based datetime group labels should be unambiguous.

The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock.

For example:

    13:00 20 Mar
    16:00 26 Mar

This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers.

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

Forward-Port-Of: odoo/odoo#275219
Forward-Port-Of: odoo/odoo#274724

Before this commit, calls to the route `/shop?search=<search_term>` would lead the search for `product_public_categories` to use a query in the shape of `product_id in (<list_of_ids>)`.
In the case where the cardinality of the product table becomes large (> 10k products), if `search_term` is very broad-spectrum, the length of `list_of_ids` reaches the size of the product table.
In that case the query generated to search for categories becomes significantly slow to parse (> 14 seconds in our tests).

This commit proposes as an alternative to resort to a sub-query to fetch the product ids that are relevant in the context of `product_public_categories`. Because of how the list of products is acquired initially, we can't rely on the `_search()` method to generate the sub-query.

The following table shows average gains for "increasing search term specificity". Here, "specificity" is determined by the amount of characters in the search term and the related number of hits expected from the search.

### Cardinality ~250k records
| Metric | ~228,872 hits | ~2,870 hits | ~377 hits | ~11 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 14.027s | 5.726s | 3.183s | 3.139s |
| After Fix | 1.216s | 3.794s* | 1.330s | 1.301s |

### Cardinality 10k records
| Metric | 8,897 hits | 1,122 hits | 15 hits | 0 hits |
| :--- | :--- | :--- | :--- | :--- |
| Before Fix | 1.386s | 3.232s* | 0.580s | 0.395s |
| After Fix | 0.756s | 3.410s* | 0.772s | 0.572s |


*Note: The increase in response time in the second column is caused by a different execution path taken (fuzzy search) which becomes the most significant path in terms of execution time once the other queries are optimized.

opw-6299343

Forward-Port-Of: odoo/odoo#271306

`_add_manual_models` builds Python model classes for custom ("manual") `ir.model` records with a raw `SELECT *` on the `ir_model` table, then hands each row to `_instanciate_attrs`, which reads a fixed list of expected columns (`model`, `name`, `abstract`, `transient`, `order`, `fold_name`, `info`) via dict subscription (`model_data['xxx']`).

This assumes every one of these fields is always backed by a real database column. That assumption breaks whenever a field originally declared as stored on `ir.model` gets redeclared as non-stored (`store=False`) by another module inheriting the same model: Odoo correctly drops the now-unneeded column during that module's `_auto_init()`, but any code still doing `SELECT *` on the table no longer gets that key in the result row, and the subscript access raises a bare `KeyError`. This aborts the *entire* registry load, for every model in the database, not just the one whose field changed -- because `_add_manual_models` runs once per registry load and any database with at least one manual/custom model exercises it.

This is exactly the scenario introduced by 267bec440d56 ("[IMP] base: add IrModel.abstract field"): it added a new, plain stored `abstract` field on `ir.model`. `web_studio` has independently defined its own `abstract` field on `ir.model` since 2016 (ac1129f6577), as a computed, `store=False` field. Once both are loaded together, Odoo's field- merging logic settles on the `store=False` definition, so `_auto_init()` drops the `abstract` column -- and any database that also has at least one manual model (built through Studio, or via a module that dynamically generates SQL-view-backed models) then fails to boot its registry at all:

    File ".../odoo/orm/model_classes.py", line 554, in _add_manual_models
        attrs = env['ir.model']._instanciate_attrs(model_data)
    File ".../odoo/addons/base/models/ir_model.py", line 487, in _instanciate_attrs
        '_abstract': bool(model_data['abstract']),
    KeyError: 'abstract'

Fix `_instanciate_attrs` to fall back to a sane default instead of assuming the column exists. This doesn't just patch the `base`/ `web_studio` collision -- it hardens `_add_manual_models` against any future field made non-stored by an inheriting module, which is otherwise a silent, whole-database-breaking failure with no visible relation to whichever module actually changed the field.

A companion fix removing web_studio's now-redundant override (the actual root cause of the collision) is proposed separately.

Steps to reproduce:
1. Install `base` and `web_studio` together (or in either order) --
   Odoo's field-merging settles on web_studio's `store=False`
   definition, but leaves the `abstract` column physically in place;
   it is not dropped automatically.
2. Have at least one manual model in the database (`state='manual'`
   on `ir.model`, e.g. created through Settings > Technical > Models).
3. Actually remove the now-orphaned `abstract` column -- e.g. via the
   OCA `database_cleanup` module's column-purge wizard
   (`cleanup.purge.wizard.column`), which explicitly targets exactly
   this kind of column (computed + non-stored fields are excluded
   from its "keep" list, so `abstract` gets flagged and dropped).
4. Restart Odoo / reload the registry: it fails to boot entirely with
   a KeyError on that field name, for every model, not just the one
   whose owning module changed.


Related: odoo/enterprise#123572



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

Forward-Port-Of: odoo/odoo#275092

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

Steps to reproduce
-------------------

- Install sale_project, accountant and project_timesheet_forecast_sale modules;
- Activate analytic accounting in the settings;
- Add an outstanding account to the bank journal’s manual outgoing payment method;
- Create a new billable project;
- Open the top menu, add vendor bills and open it;
- Create a new bill from there, it should use the project’s analytic distribution;
- Confirm it and create a payment;
- Open the payment’s journal entry, it is using the analytic distribution too;

Why is it happening
--------------------

When opening a vendor bill from the project, the project_id is added to the account.move's context to use the correct analytic distribution when we create a  bill.

If we create a payment after accessing the bill from this route, the context is transfered to account.payment.register, and then to the payment's entry lines in the `_create_payments` method.

Due to the `_compute_analytic_distribution` method, the project's distribution is used on the payment's entry.

We propose to filter out payment lines in this compute method.

opw-6329475


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

Forward-Port-Of: odoo/odoo#275076

# How to reproduce
- Create a new product
- Add a reordering rule to that product with :
	- Trigger : Auto
	- Min : > Forecast
- Activate dev mode
- Go to Seetings > Technical > Automation > Scheduled Actions
- Find the "Procurement: run Scheduler" action & run it manually

# The issue
We get a traceback :
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

# Cause
In Odoo, we use an isolation level of "REPEATABLE READ" for transactions :
https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/odoo/sql_db.py#L373

Even with that isolation level psql can throw a `SerializationFailure` if a transaction
attempts to update a row that was modified by another transaction after the isolation
snapshot was taken.

### Example that will raise an error :

Session 1
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
```

Session 2
```SQL
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
```

Back to Session 1
```SQL
COMMIT;
```

When running our action, we do this :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_rule.py#L697-L703

Which correspond exactly to the first example :
We first update some records with their compute

Then `orderpoints.sudo()._procure_orderpoint_confirm(...)` creates a new
transaction, update some rows & commits :
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L716-L719
https://github.com/odoo/odoo/blob/dff0835346f30fd1ef77260d94bcceeeab4d9051/addons/stock/models/stock_orderpoint.py#L781-L783

Finally, we commit the original transaction with `_commit_progress(1)`

# Proposed solution
Inverse the order of  `_commit_progress(1)` and
`orderpoints.sudo()._procure_orderpoint_confirm(...)` so we commit
the first transaction before starting the second one.

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

Forward-Port-Of: odoo/odoo#268616

In the bubble layout, the `name="company_address"` div was inside an unconstrained `<td>`, causing percentage-based widths set in `company_details` (e.g. `width: 25%` on a image) to resolve against the full table cell width, resulting in oversized content compared to other layouts.
**Without fix:**

<img width="1127" height="411" alt="withoutfix" src="https://github.com/user-attachments/assets/244c3407-1dbb-4b83-95d9-ebaba2b2b13c" />

For e.g, The folder layout wraps the same block in a `w-50` div, so percentage widths resolve against ~half the page width.

<img width="1111" height="410" alt="folderexp" src="https://github.com/user-attachments/assets/ee72712a-94da-483c-9a8e-cb3a850dac8e" />

Added `w-50 ms-auto` to the `name="company_address"` div in the bubble layout to align its sizing context with the other layouts, ensuring consistent rendering of user-defined styles in `company_details` across both layouts.

**With fix:**

<img width="1119" height="413" alt="wfix" src="https://github.com/user-attachments/assets/6b1caf24-3a8e-450f-865e-cce2b9788fe9" />



Commit which made the bubble layout in table: https://github.com/odoo/odoo/commit/8eb61a245cd3b650e309fdb55d24654c34d785cd

opw-6287230



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

Forward-Port-Of: odoo/odoo#275228
Forward-Port-Of: odoo/odoo#270725

When opening a table that has no order, `setTable` recycles an existing empty floating order instead of creating a new one (to avoid leaving dangling blank orders behind). The filter only checked for the absence of a table, lines and finalized state, so it could grab any empty floating order, including one deliberately created for takeout or delivery.

Steps to reproduce:
- Open a restaurant POS with presets enabled (e.g. Dine in / Takeaway).
- Cashier A creates a new floating order for a phone customer: selects the Takeaway preset with a future time slot, but has not added any product yet.
- Meanwhile, cashier B opens an empty table from the floor screen.
- => The takeout order is assigned to the table and becomes a dine-in order, losing its takeout context.

Only recycle blank direct sale orders: skip orders that have a floating order name, a scheduled preset time or a preset different from the config default, as those were created on purpose. Tapping a table while on a blank dine-in scratch order still converts it as before.

opw-6041750

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

Forward-Port-Of: odoo/odoo#262573

Steps to reproduce:
- Create a promotion program (e.g. "10% discount on your order", reward_point_mode "per order") and restrict its rule to a specific product A; leave the minimum quantity at 0
- Open a PoS session and add any other product B to the order

Issue:
The discount was applied even though the order contained none of the rule's valid products.

Cause:
In `pointsForPrograms`, a rule was only gated on its quantity and amount thresholds (`totalProductQty < rule.minimum_qty`), never on the actual presence of a valid product in the order. Program templates (promotion, promo_code, next_order_coupons) create rules with minimum_qty = 0, so a product-restricted rule passed with zero matching items and, in "order" point mode, granted its points unconditionally. The same hole existed in `_canGenerateRewards` for scanned coupon programs, where rules act as conditions.

The backend does not have this issue: `_program_check_compute_points` in sale_loyalty skips any rule whose valid products are not present in the order.

Fix:
Mirror the backend behavior in the PoS frontend: skip a product-restricted rule in `pointsForPrograms` when no (non-reward) order line matches its valid products, and make `_canGenerateRewards` return false in the same situation. Gift card and eWallet flows are unaffected since their "money"/"unit" point modes already gave 0 points when the trigger product was absent.

opw-6357241

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

Forward-Port-Of: odoo/odoo#275073

When uploading a font file "FontName 123 Light.otf" the baseFontName needs to be quoted in the font-face CSS to be valid.

Single font files parsing for the shortestNamedFont now also correctly keeps the weight for the targetFonts.

Description of the issue/feature this PR addresses:
Uploaded fonts with spaces in the name are not working.

Current behavior before PR:
When uploading a font with a space in the filename like  "FontName 123 Light.otf" the css declaration in the attachement is wrong and not working:
```css
@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Desired behavior after PR is merged:
The font name is now correctly quoted and the font attributes are no longer overwritten for the shortestNameFont:
```css
@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 300;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Info @wt-io-it

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

Forward-Port-Of: odoo/odoo#273534
Forward-Port-Of: odoo/odoo#268842

#### Issue:
When a credit note is renamed so that it sorts before the related invoices,
the lot assigned on invoice previews can become incorrect. Already posted
invoices can appear to consume the first lot again.

Example:
A sale order is delivered in 2 batches: 10 units from SN01, then 10 units
from SN02. Invoice 1 correctly shows SN01 and Invoice 2 correctly shows
SN02. If Invoice 1 is refunded, re-invoiced, and the credit note is then
renamed so it sorts before the invoices, Invoice 2 can incorrectly switch
back to SN01.

#### Steps to reproduce:
- Enable "Display Lots & Serial Numbers on Invoices".
- Create a sale order for 20 units of a tracked product.
- Deliver 10 units from the first lot/serial number and 10 units from a second one in a backorder.
- Create and post 2 invoices, one for each delivery.
- Create and post a credit note for the first invoice.
- Create and post a new invoice for 10 units.
- Reset the credit note to draft, rename it so that it sorts before the invoices, then repost it.
- Check the lot previews on the invoices.

#### Root Cause:
_get_invoiced_lot_values() orders invoice lines with move_name, which is
mutable, then computes the previously invoiced quantities from that order.
When a refund is renamed so it sorts before the invoices, the set of
"previous" invoice lines changes. On top of that, reversed invoices are
filtered out too broadly, even when their reversing move should not yet
impact the current invoice chronology.

#### Fix:
Order invoice lines with immutable move ids instead of move_name, and only
ignore reversed invoices once their reversing move is also before the
current invoice in the effective chronology. This keeps posted invoices
stable while preserving the re-invoice behavior.

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

Forward-Port-Of: odoo/odoo#264776

When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused them to be grouped separately. This caused a discrepency between the tax amount computed in the frontend and the one computed in the backend.

Steps to reproduce:
-------------------
* Change the rounding method to globally
* Create a 21% tax not included in price
* Create a product with a price of 76.01 and the tax created above
* Create a loyalty program with a 10% discount
* Create a POS order with the product above and apply the loyalty program
* Validate the order and generate the invoice
> Observation: The invoice states that 0.01$ is still due

Why the fix:
------------
In `round_tax_details_tax_amounts`, we try to detect any delta with the expeced tax amount. To do that we group the base lines based on a grouping key. The grouping key `is_refund` was incorrectly set to `true` for reward lines, which caused them to not be grouped. The delta was then not detected and tax amounts were not adjusted. We now make sure not to consider reward lines as refund.

opw-6052112

Forward-Port-Of: odoo/odoo#275145
Forward-Port-Of: odoo/odoo#271577

When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `Procurement Exception` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user.

Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.

System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs. Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity.

This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.

Steps to Reproduce on Runbot/Fresh Database on version 17.0:
1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
2. Restrict the main Admin (Runbot) user strictly to Company A.
3. Create a Shared Product (Company field left blank).
4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
8. Check the chatter for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.

[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)


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

Forward-Port-Of: odoo/odoo#275140
Forward-Port-Of: odoo/odoo#269395

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

…nding

When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be marked as paid.

Steps to reproduce:
- Enable cash rounding (e.g. 0.05, HALF-UP) with "Only for cash payment methods"
- Create an order with a total of 15.28
- Add a cash payment of 10.00, then an online payment for the remainder

The frontend requests 5.28 for the online payment, but as soon as the order contained a cash payment the server rounded the whole order total: get_and_set_online_payments_data() returned an unpaid amount of 5.30 (15.30 - 10.00), so the validation failed with "Invalid online payments".

Even once the online payment of 5.28 was processed, the order remained stuck in draft with the money captured: _is_pos_order_paid() compared the paid amount (15.28) against the rounded total (15.30).

Only the part of the order actually settled in cash must be rounded: non-cash payments (card, online, ...) always pay their exact share.

- get_amount_unpaid() now returns the exact residual of the order when the rounding only applies to cash payment methods.
- _get_rounded_amount() now only rounds the amount not covered by non-cash payments, resolving its old TODO. Cash-only orders and orders where the cash payment settles the rounded remainder are unaffected.

opw-6314690

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

Forward-Port-Of: odoo/odoo#275305

**Steps to reproduce:**
- Install the `l10n_it_edi` module and switch to an IT Company.
- Create and confirm an invoice for a non-Italian customer.
- Send the invoice, making sure that only `by Email` is enabled.
- Attempt to send the invoice again.

**Issue:**
- In `18.0`, the XML file is not generated when re-sending an invoice that 
was previously sent only by email.

- Starting from `19.0`, attempting to `Send to Tax Agency` raises an error:
`UnboundLocalError: cannot access local variable 'attachment_name' where it is not associated with a value`

**Root cause:**
At [1], `_get_alerts` method does not check whether the invoice was previously 
sent only by email. As a result, the warning banner is not displayed, and 
allows the user to `Send to Tax Agency`.

**Fix:**
Restore the expected behavior by preventing `Send to Tax Agency` when 
the invoice was previously sent only by email. Instead, display the 
appropriate warning message instructing the user to delete the 
PDF attachment before sending to the Tax Agency, matching the 
behavior in `17.0` (confirmed with PO).

[1]:
https://github.com/odoo/odoo/blob/c0d8d36481e106f0209521bbb127cb3b1ad1059a/addons/l10n_it_edi/models/account_move_send.py#L27-L33

opw-6293519

Forward-Port-Of: odoo/odoo#269547

Steps to reproduce
-------------------

- Install sale_project, accountant and project_timesheet_forecast_sale modules;
- Activate analytic accounting in the settings;
- Add an outstanding account to the bank journal’s manual outgoing payment method;
- Create a new billable project;
- Open the top menu, add vendor bills and open it;
- Create a new bill from there, it should use the project’s analytic distribution;
- Confirm it and create a payment;
- Open the payment’s journal entry, it is using the analytic distribution too;

Why is it happening
--------------------

When opening a vendor bill from the project, the project_id is added to the account.move's context to use the correct analytic distribution when we create a  bill.

If we create a payment after accessing the bill from this route, the context is transfered to account.payment.register, and then to the payment's entry lines in the `_create_payments` method.

Due to the `_compute_analytic_distribution` method, the project's distribution is used on the payment's entry.

We propose to filter out payment lines in this compute method.

opw-6329475


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

Forward-Port-Of: odoo/odoo#275076

all_sm is referenced by two branches of the outer UNION, so PostgreSQL materializes it (a CTE used more than once is an optimization fence). Every query on report_stock_quantity therefore builds the forecast for all products/warehouses first and filters afterwards, so predicates like product_id can't reach the stock_move scan.

This hurts single-product lookups such as _read_group() in mrp_report_bom_structure._get_stock_availability(), called repeatedly per component while rendering a BoM report: each call does a full stock_move scan plus two sorts that spill to disk.

Marking all_sm NOT MATERIALIZED lets the planner inline it and push the product_id/warehouse_id filter down to an index scan, removing the full scan, the GENERATE_SERIES expansion and the on-disk sorts. warehouse_cte stays materialized (small and cheap).

Query generated from the _read_group:
```SQL
SELECT MIN("report_stock_quantity"."date")
FROM "report_stock_quantity"
WHERE (
        (
            (
                (
                    ("report_stock_quantity"."state" = 'forecast')
                    AND ("report_stock_quantity"."date" >= '2026-07-08')
                )
                AND ("report_stock_quantity"."product_id" = 15743)
            )
            AND ("report_stock_quantity"."product_qty" >= 1.0)
        )
        AND ("report_stock_quantity"."warehouse_id" = 4)
    )
    AND ("report_stock_quantity"."company_id" IN (1))
```

Before:
800 ms by _read_group in _get_stock_availability().
For opening a BoM overview with hundred of components takes 17 sec.

After:
25 ms by _read_group in _get_stock_availability().
Same BoM overview drops to 3 sec to open.

cc @Aurelienvd 



I can send you EXPLAIN ANALYZE, but I prefer to not putting them here to avoid data leakage.

Forward-Port-Of: odoo/odoo#275022

Let's consider we have validated the return of our tax report for January and February. Then, we realize we made an error in January, and want to modify this return and resubmit it.

Before this commit, an error message blocked the direct resetting of January's return, because February's had been posted. To be able to reset January, it was necessary to reset all subsequent returns. This was annoying. Such fixes need to happen in many countries (while some other rather make the adjustments in the next period to declare, like Belgium).

This restriction was originally introduced to avoid inconsistencies in case the returns declared from the previously submitted returns. Two features could create such cases:

1) tax amount to recover, which was directly deduced from the closing entry when it contained something to pay

2) carryover, which created external values able to impact the following periods

=> Case 1) is not true anymore. When an amount needs to be recovered, we just show the balance taking it into account on the following returns, but don't change anything to their closing at all.

=> Case 2) still holds.

So, all we need to put under control is carryover, which is what we do now. If the report doesn't use carryover at all, its returns can all safely be reset, whatever the state of the rest of the return chain.

## 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#122813
Forward-Port-Of: odoo/enterprise#122035

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121809
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Journal entries and create a new one
3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of existing fields
4. Add 2 lines (example):
	1. account Product Sales with 1000 dollars credit and 15% tax under Tax column
	2. account Bank with 1000 dollars debit
5. Go to Dashboard > Bank > Click the 3 dots of one random bank matching line and click on Manage Models
6. Go to bank fees and add the 15% tax
7. Go back to bank reconciliation and create a new one of 2000 dollars with label bank fees (it will associate the tax automatically)
8. Go back to Journal Entries, group by Journal and search for the transaction of 2000 sollars for account Bank
9. Problem: see that the Base Amount for the 15% bank fees lines (251000 Tax Received account) is 0. Clicking on Reset to draft button the base amount column is automatically updated but this should happen automatically

### Cause of the issue:
This occurs because the _lines_prepare_tax_line method in account.bank.statement.line fails to map this field in its return dictionary.

### Reason to introduce the fix:
Currently, when applying a reconciliation model with taxes the generated tax lines incorrectly record a tax_base_amount of $0.00. Instead, it should be displayed and calculated.

opw-6220948

Forward-Port-Of: odoo/enterprise#123603
Forward-Port-Of: odoo/enterprise#122139

Steps to reproduce:
1. Install sale_crm and sale_renting_crm
2. Create an opportunity
3. On this opportunity, create two quotations from the `New quotation` button
4. From the opportunity's form view, click on the `Quotation` smart button

Issue:
- The quotations are not visible in the list view

Why?
- In module `sale_renting_crm`, we override the domain to exclude rental quotations.
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting_crm/models/crm_lead.py#L33-L36 But from the saas-19.3 `is_rental_order` field is no longer stored in the DB, It is computed now and filtered through  `_search_is_rental_order`. 
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting/models/sale_order.py#L223-L227 The search method did not properly handle the Boolean search shape used by the ORM, so the quotations were incorrectly filtered out. In our case, we gave the domain `("is_rental_order", "=", False)` but the operator is translated to `not in` and value to `Orderedset([True])` by the domain optimiser

Solution:
- Update `_search_is_rental_order()` to handle the ORM-normalized boolean search correctly for rental and non-rental quotations.

opw-6304696

Forward-Port-Of: odoo/enterprise#120869

Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).

The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.

```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
    setStart@[native code]
    createEditorSelection@.../web.assets_web.min.js:12239:15
    getSelectionData@.../web.assets_web.min.js:12242:145
    updateActiveSelection@.../web.assets_web.min.js:12230:92
    @.../web.assets_web.min.js:12218:873
    handler@.../web.assets_web.min.js:14366:121
```

Steps to reproduce:

1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
   Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
   so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.

Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.

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

_**Steps to reproduce:**_

* Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings.
* Switch to a Polish company.
* Create an EU customer with a valid VAT number.
* Create a sale order containing a service product taxed with **0% EU S**.
* Confirm the sale order and create a down payment invoice.
* Send the invoice to KSeF and inspect the generated XML.

**_Observed behavior:_**

* The generated KSeF XML does not contain the `P_13_9` field.

**_Cause:_**

* For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document.

**_Fix_**:

* Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML.
* This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

opw-6294181