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

When opening the media dialog to edit an image or when saving a
selected image, the UI crashes with strict prop validation and
undefined property errors.

This occurs due to recent refactoring in the `html_editor` framework. 
First, the base `MediaDialog` now strictly requires the `document` 
object as a prop. Because it was omitted in the payload, Owl's validation
rejected the component. Second, the dialog's state management was updated,
meaning `activeTab` is no longer accessed via `this.state.activeTab`, but
rather via the `this.activeTab()` method.

This commit fixes these issues by passing `window.document` into the 
dialog's initial props and when calling `renderMedia`. It also updates how
we access activeTab.

**Steps to reproduce:**

- POS > Products > Products > choose any product > click the ‘edit’ button in the image > search something, e.g. ‘burger’ > select one of the resulting images

**Current behavior before PR:**

- Errors either after clicking the 'edit' button or after selecting one of the resulting images

**Desired behavior after PR is merged:**

- No errors when editing or saving images

opw-6445843

Problem:
Interrupted uploads or malformed email payloads can create 0-byte binary `ir.attachment` records where the `checksum` is `False`. Accessing the computed `image_src` field on these records triggers a `TypeError: 'bool' object is not subscriptable` when attempting to slice `attachment.checksum[:8]`. This crashes the Media Dialog and Chatter.

Purpose:
Add a fallback boolean guard to `attachment.checksum` inside `_compute_image_src` so that empty attachments evaluate safely to a string ('0') instead of raising a traceback, allowing the UI to render gracefully.

Steps to Reproduce on Runbot:
1. Go to Settings > Technical > Database Structure > Attachments.
2. Create a new record: Name: `test.png`, Type: `File` (Binary), File Content: [leave empty], Is public document: Checked.
3. Open any record with a Chatter (e.g., Contact or CRM Lead) and click "Insert Image" to open the Media Dialog.
4. The system attempts to evaluate `image_src` and throws the `TypeError`.

Notes:
A test (`test_compute_image_src_empty_checksum`) was added to `test_ir_attachment.py`

opw-6482674

Forward-Port-Of: odoo/odoo#287758
Forward-Port-Of: odoo/odoo#287444

Steps to reproduce
---
1. Set the warehouse to deliver in 3 steps.
2. Create a delivery pick not tied to a procurement group (not from a sale order) with a consumable product, and validate it.
3. On the pack transfer, put the goods in a package and validate.
4. Duplicate the pick, validate it, put its goods in a second package on the pack transfer, and validate.
5. Open the final delivery: both lines sit in the same package instead of one line per package.

Issue
---
The two picks share no procurement group, so their delivery moves merge onto a single move keyed by partner. Validating the second pack tops up that already partially reserved move: for a consumable, `_action_assign` builds its lines from `_get_available_move_lines`, which reports the availability of every upstream package without discounting what the move already reserved.

https://github.com/odoo/odoo/blob/05af9e6877fd0f044bb46c983fe7300eb1db9307/addons/stock/models/stock_move.py#L1907-L1909

The package already reserved on the first line is therefore offered again and reused, collapsing both lines onto one package. The reserved-product branch below already subtracts the move's own reservation before allocating; doing the same here leaves each package on its own line.

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

Forward-Port-Of: odoo/odoo#287935
Forward-Port-Of: odoo/odoo#284956

Go to Manufacturing > Planning > Workorders > Planning > list view. Sample data are displayed. Remove a filter such that real records match the domain. Tracebacks are displayed because we call `get_duration` on records that don't exist.

The `useRecordObserver` of MrpTimerField subscribes the callback to the `useSampleModel` flag and to the `record`. When the filter is removed, the model is reloaded and, atomically, both the flag and the root and updated on the model. As the flag is toggled, the callback is executed. However, the props of the MrpTimerField aren't updated yet, so the `record` used in the callback is still the old, sample, one.

One could argue that there's a design flaw in the model as at some point, a `record` could contain sample data while it's model states that we're not in sample mode (`record.model.useSampleModel` is false). That's true and that's something we'll change in the future, but in master.

We fix this issue with an easier patch, which consists in accessing the `useSampleModel` flag with `untrack`, i.e. to not subscribe to that flag's changes, as in that case, the component will be destroyed anyway.

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

Currently, an error occurs when the user sets the partner's country to Saudi Arabia.

**Steps to Reproduce:**
 - Install the `l10n_sa` module with demo data.
 - Switch to `My Saudi Arabia Company`.
 - Create a `partner` and click the `+` icon next to the VAT Number.
 - Select `Company ID`, set any `value`.
 - Set the partner's country to `Saudi Arabia`.

`KeyError: 'OTHER'`

After the [recent commit], OTHER is removed from vals [1] when at least one other EN identifier, 
excluding OTHER, is available. If a user selects OTHER (Company ID) as an additional identifier 
and then changes the partner's country to Saudi Arabia, the available additional identifier 
metadata is recomputed. With the [second commit], it checks whether the stored additional 
identifier is applicable to Saudi Arabia by looking up its metadata [2].
However, since OTHER was removed from the available additional identifier metadata because 
another EN identifier is available, directly accessing the metadata for OTHER raises a KeyError.

This commit ensures that the additional identifier is safely accessed in the metadata.

[recent commit]: https://github.com/odoo/odoo/commit/9087c2ddc1de3e9ef9431188a9b6dddbd6b58552

[second commit]: https://github.com/odoo/odoo/commit/fddf7653ba898f5db9d97ae3cd9f885c6c5c658a

[1]- https://github.com/odoo/odoo/blob/1d50ff71a1edf2c4226cb2f68cf3bbe4e39485f6/odoo/addons/base/models/res_partner.py#L1423-L1425

[2]- https://github.com/odoo/odoo/blob/1d50ff71a1edf2c4226cb2f68cf3bbe4e39485f6/addons/l10n_sa/models/res_partner.py#L17-L18

sentry-7717445803

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

The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with 6 decimals while the SAT expects the amounts to be expressed with the number of decimals supported by the currency of the payment ('MonedaP'), as published in the 'c_Moneda' catalog, for example 2 decimals for MXN.

Steps to reproduce:

- Have an MX Company setup with Quadrum as PAC.
- Create and sign a customer invoice in MXN with a 16% IVA tax.
- Register a full payment and send the payment complement to the PAC.

Issue:

Payment will be rejected
```
Code : CRPER654
Message : El importe del campo BaseP que corresponde a Traslado, no tiene la cantidad de decimales que soporta la moneda (MonedaP)
```

Analysis:

Quadrum recently aligned its validation on that rule and now rejects the document having fields with too much decimals and, currently, fields like BaseP, ImporteP are pinned to 6 decimals in the template.

Reporting them with the decimals of the payment currency is not enough when the payment settles a document expressed in another currency: those amounts are also compared with the ones of the related documents converted with 'EquivalenciaDR', and the PAC expects the values truncated or rounded

```
Code : CRP20274
Extra Info : Traslados: La sumatoria de ImporteDR es mayor al ImporteP 1.30.
             Valores minimos permitidos: Truncado: 1.29 o redondeado: 1.3
```

opw-6561617

Forward-Port-Of: odoo/enterprise#131343
Forward-Port-Of: odoo/enterprise#131267

Current behavior:
--
Sending a B2B invoice that deducts a down payment is rejected by ECPay with
"(item tax discrepancy exceeds 1 NT$)", so the invoice
cannot be issued at all. When it is accepted, the tax on the e-invoice can
still differ from the tax the invoice books.

Expected behavior:
--
The invoice is accepted, and the tax reported on the e-invoice is the one the
invoice booked.

Steps to reproduce:
--
- Set a company up in Taiwan (TWD) with the ECPay credentials filled in
- Create a sale order of 190,630 for a customer with a VAT number
- Invoice a 50% down payment through the down payment wizard, then a 30% one, and post both
- Invoice the remainder and post it
- Send the final invoice to ECPay

Cause of the issue:
--
_l10n_tw_edi_prepare_item_list rebuilt the tax from the raw amount of every
line and rounded that total once. Both steps also disagree with the invoice. 
Negative lines resulting from downpayments seem to be more strictly checked
on ECPay and taxes cannot be re-derived easily by ECPay's system.

There is a also a relevant but slightly different issue where the invoice amount is calculated
differently but the ECPay page will show a different value.

e.g. the invoice rounds each
computation key on its own: 50.00 - 16.50 = 33.50 rounds to 34 where the invoice books
50 - 17 = 33.

No issue was detected for purely positive lines (a transaction with
different products but no downpayment)

Fix:
--
Use the tax amount the line carries when it has one, and fall back to the raw
amount otherwise, so the payload reports what the invoice booked. Send the tax
of each line in the ItemTax field. Let ECPay derive its own per-item tax and checks
it against the declared total for purely positive lines, and recalculate them for negative
so the rounding difference between them is spread one unit at a time across the lines,
the way ECPay distributes it.

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

Forward-Port-Of: odoo/odoo#281928

Currently on creating  new helpdesk team everytime a new website menu is created.

### **Steps to Reproduce:**
1) Install website_helpdesk
2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 
3) Create 2 helpdesk team with `Website Form` option enable. 
4) Navigate to Website.

### **Observed Behavior:**
Two Help menus are created.

### **Expected Behavior:**
Multiple menus should not be created.

### **Root Cause:**
The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112)
`team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`,
which keys its result by the `website_id` *recordset*, not its id. Looking it
up with `team_count_by_website.get(website.id, 0)` therefore always misses and
falls back to `0`, so `team_count <= 1` is always `True` regardless of how
many teams already exist for that website. The only thing left guarding menu
creation is `any(team.website_menu_id for team in teams)`, which only looks at
the teams in the current create/write call, not every team on that website.
So saving a second team in a separate call always creates another menu.

### Fix:
Make the website menu a resource shared by every team with the website form
enabled on a given website, instead of "owned" by whichever team created it:
- Before creating a new menu, look up other teams (active or archived) that
  already point to a menu, matched through the `website_menu_id` relation
  between teams rather than a hardcoded `/helpdesk` URL, so a customized menu
  URL doesn't cause a duplicate to be created. Reuse that menu when found.
- Only delete a menu once no team (active or archived) still references it,
  checked before removing a team's own reference.

**opw-6303846**

Forward-Port-Of: odoo/enterprise#130401
Forward-Port-Of: odoo/enterprise#121120

Since the introduction of `read_grouping_sets` for Pivot views, opening the Pivot view from a saved favorite filter can crash.

### **Steps to reproduce:**
- Install Project.
- Open My Tasks.
- Save the current filter as a favorite.
- Switch to the Pivot view.

### **Error:**
```
ValueError: Cannot convert project.task.personal_stage_id to SQL
because it is not stored.
```

### **Root Cause:**
Since [commit](https://github.com/odoo/odoo/pull/194413/changes/166a546ec52784c413f5b5d7d29af89d618d6519), Pivot views use `_read_grouping_sets` instead of
`_read_group`. `project.task` only remaps `personal_stage_type_id` to the stored `personal_stage_type_ids` in [_read_group](https://github.com/odoo/odoo/blob/5f6fb63d5d7585805642c702d096b2f882e73761/addons/project/models/project_task.py#L2169-L2179), so the remapping is bypassed for Pivot views. The ORM then attempts to group by the non-stored `personal_stage_type_id` relation, leading to the SQL conversion error.

### **Fix:**
Mirror the remapping logic in `_read_grouping_sets` so Pivot views use `personal_stage_type_ids` before the ORM generates the SQL query.

**opw-6306389**

Forward-Port-Of: odoo/odoo#272985

Steps to reproduce:
---
- Install the website_sale module with demo data.
- Go to /shop and switch the product layout to Chips.
- Exit the editor.
- On the home page, open the editor and add the Dynamic Products snippet.

Issue:
---
The Products snippet has collapsed card padding when the Chips layout is active.

Root cause:
---
- The Chips card layout defines `--_padding-base` using
`var(--o-wsale-products-grid-gap)` with no fallback value.

https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/static/src/scss/product_tile.scss#L632

- When the Products snippet renders outside /shop, the variable is
undefined, causing the `calc()` to resolve to a guaranteed-invalid
value which collapses the card padding. All other layouts are
unaffected because they either do not use `--o-wsale-products-grid-gap`
in their padding chain, or already provide a `16px` fallback at the
point of use.

https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/static/src/scss/product_tile.scss#L407-L410

Solution:
---
- 16px matches the default value of `shop_gap` on the website model,
ensuring correct padding whenever the variable is not explicitly set.

https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/models/website.py#L128
  
### Before:
<img width="1456" height="563" alt="image" src="https://github.com/user-attachments/assets/c28ab183-0af3-4a2a-858d-b85d9995eb07" />

### After:
<img width="1427" height="550" alt="image" src="https://github.com/user-attachments/assets/e0ba80ec-10ad-433f-bf9a-acbaffd56a76" />

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

Forward-Port-Of: odoo/odoo#286185

Steps to reproduce
------------------
- Install `website_sale_stock` and `sale_management` module.
- Create a product.
- Create a rule-based delivery method with:
- In Pricing tab click add a line
  - condition: `Quantity >= 0`
  - variable factor: `weight`
  - price per unit: 2
- Create a quotation containing the product.
- Open the delivery method wizard by clicking into `Add Shipping`
- Select the rule-based delivery method.
- Change the total weight from 0 to 10.
- Add the delivery method.

Issue
-----
- Changing the total weight does not recompute the delivery price.
- The delivery line is added with a price of 0 instead of 20.

Cause
-----

The delivery wizard defines `_onchange_carrier_id` for both `carrier_id` and `total_weight`

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/wizard/choose_delivery_carrier.py#L41-L50

The call flow is expected to be:

`total_weight` change
-> `_onchange_carrier_id`
-> `_get_delivery_rate`
-> `rate_shipment`

`_get_delivery_rate` passes the manually entered weight through the `order_weight` context key:

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/wizard/choose_delivery_carrier.py#L87-L90

The rule-based carrier gives this context value priority over the saved order weight and the weight computed from order lines:

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/models/delivery_carrier.py#L588-L594

For example, with `total_weight = 10` and a price factor of 2, the expected calculation is:
`delivery_price = 0 + 2 * 10 = 20`

However, the pickup-location implementation added an override in `website_sale_stock` that declared only `carrier_id` as an onchange trigger:

https://github.com/odoo/odoo/blob/0da3259034ff3b2b79f417df53969fe017207195/addons/website_sale_stock/wizard/choose_delivery_carrier.py#L13-L16

Since the override uses the same method name, its decorator replaces the base onchange specification. Therefore, changing `total_weight` does not call the method and the initial `delivery_price = 0` is kept.

This does not occur in saas-19.2. because `website_sale_stock` does not override the delivery wizard there. The base method remains registered for both `carrier_id` and `total_weight`:

The conflicting override was introduced later in this [commit](https://github.com/odoo/odoo/commit/0da3259034ff3b2b79f417df53969fe017207195) from saas-19.3

Fix
---

Add `total_weight` to the `website_sale_stock` onchange decorator 
so the inherited delivery-rate computation runs when the user edits the weight.

---

opw-6516301

---

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

Forward-Port-Of: odoo/odoo#285864