Steps to reproduce:
------------------------------------
1. Install the Knowledge module.
2. Open any article.
3. Click the header icon. If no icon is present, add one from the Actions menu.
4. Click the header icon again.
5. Click Remove icon from the emoji picker.

Observation:
------------------------------------
A traceback is raised when removing the header icon. 
```
TypeError: Cannot set properties of undefined (setting 'scrollTop')
```

Issue:
------------------------------------
The emoji picker component updates its scroll position through a grid reference.

After this PR - https://github.com/odoo/odoo/pull/269588, the emoji picker was migrated to Owl 3, which changed the way component references are handled. The header icon removal flow still uses the previous ref access pattern, causing the grid reference to be `undefined` when attempting to update `scrollTop`, resulting in a traceback.

Solution:
------------------------------------
Update the syntax for accessing the ref signal.

### 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

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

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

Problem:
When creating a product from an invoice form view, the list price set on the product is not saved on the product template. After creating the product, when checking the product from the products list, the set list price is not shown.

Steps to reproduce:
1. Go to Accounting > Customers > Invoices
2. Create a new invoice
3. Create and edit a new product from the invoice line and set a new list price for the new product
4. Go to Sales > Products and open the created product
5. Check the list price of the product
6. Notice how the set list price is not shown on the product form view

Cause:
Product variants show lst_price while product templates show list_price on their form views. When creating a product from the invoice line, the shown form is for the product variant. When setting the list price on
the product variant form (lst_price in that case), the inverse method of llst_price, which sets the list_price in return, is called during the creation of the variant, after the template has been created and saved. As a result, editing the list price does not trigger a write on the already saved product template, causing the list_price of the variant to
be different than the list_price of the template.

opw-6272825

Forward-Port-Of: odoo/odoo#270614

`ImDispatch.subscribe()` lazily starts the dispatcher thread with:

```py
    if not self.is_alive():
        self.start()
```
However, this check isn't atomic: two subscribers can reach it at the same instant (a bunch of clients reconnecting after a downtime/restart/etc..) and two of them can have the condition "is not alive" and both of them will call `start()`.

Technically, this is not a big deal, since `Thread.start()` will only successfully starts once and raise an Error `Threads can only be start3e once` which is already catch and ignored with `contextlib.suppress(RuntimeError)`.

But this is a problem with some APM (like sentry) where they override `threading.Thread.start` to do something different than stdlib, and so something we can not know nor control.

The RuntimeError guard only tells us who's allowed to actually spawn the thread. It says nothing about code attached to `start()`/`run()` that runs on every attempt, win or lose, and that's exactly the part we don't control.

For example, sentry-sdk (before 2.34) patches `Thread.start` to wrap `self.run` on *every* call, not only the one that actually starts the thread:
```py
    def sentry_start(self, *a, **kw):
        self.run = wrap(self.run)      # <- side effect, runs unconditionally
        return real_start(self, *a, **kw)
```
Under the race described above, every losing call still wraps `self.run` before failing. Each wrapper forwards its own extra argument to the one it wraps, without dropping what it already received, so each layer adds one more positional argument. By the time the thread actually starts, `ImDispatch.run()` ends up called with N positional arguments instead of one:
```
    TypeError: ImDispatch.run() takes 1 positional argument but N were given
```
N varies from one report to the next simply because it depends on how many subscribers happened to race on that particular restart.

Rather than relying on the RuntimeError to paper over a race we still allow to happen, we remove the race itself: wrapping the check and the `start()` call in a lock guarantees at most one caller ever gets past the "not alive" check. `start()` is called exactly once, so there's nothing left for third-party instrumentation to react to more than once.

Note:
Reproduced locally by firing many concurrent `subscribe()` calls at a freshly created `ImDispatch` with sentry-sdk 1.39.2 installed: the TypeError appears reliably, with the reported argument count matching the number of racing calls. The same scenario no longer fails once the lock is in place, regardless of the sentry-sdk version installed.

sentry-3928947199

Forward-Port-Of: odoo/odoo#275084

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