Steps to reproduce:
==================
1. Add a Donation snippet on a page
2. Click "Donate Now"
3. Switch the website language on the payment page

=> Configured amounts/descriptions disappear

Cause:
======
The donation snippet posts its configuration (prefilled amounts, display options, descriptions) in the request body. If the user switches the website language on the payment page, it triggers a page reload via a GET request which drops the original form body (this also applies to a simple page refresh). As a result, the kwargs were empty and the page fell back to the default free-amount input, losing the configured options.

Solution:
=========
Implement Post/Redirect/Get: on POST, redirect to /donation/pay with the options in the query string so any later GET (language switch, refresh, iframe src reload) re-renders a fully configured page without losing data.

Alternative Solution:
=====================
We could also store the options in the session, but the current solution is much simpler and avoids session pollution.

opw-6282391

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

Forward-Port-Of: odoo/odoo#271460

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

Fix a series of service fee defects and add the missing coverage.

Discounts:
- stop duplicating the service fee line every time a global discount is (re)applied: reconciliation is keyed on tax_ids alone, so the discount line's computation_key is stripped to keep products and discount in one tax group;
- recompute a post_discount fee after a 100% discount deletes the now-zero discount line (which emits no event, leaving a stale fee) (pos_discount);
- keep a single fee line when a gift card / eWallet program is used (pos_loyalty).

Fixed fee:
- scale a fixed fee exactly with its quantity (5 x $2 = $10.00, not 9.99 from per-unit tax rounding);
- fix the fixed fee being off by one cent on recompute.

Refunds:
- a refund order has no preset of its own, so recomputeServiceFees falls back to the refunded order's preset and mirrors the fee proportionally: a percentage fee is correctly signed from the (negative) refund basket, a fixed fee is scaled by the refunded fraction;
- the fee must not also be refunded as an individual line (which would subtract it twice): it is excluded from auto-selection and a manual click is rejected with a warning.

Restaurant:
- keep the fee pinned to the bottom of the order (the last course) as courses are added.

task-6372687

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

Forward-Port-Of: odoo/odoo#277386
Forward-Port-Of: odoo/odoo#275684

_**Description of the issue/feature this PR addresses:**_
SaleOrder._onchange_order_line retrieves the linked lines of each order line by calling SaleOrderLine._get_linked_lines(). 
That method filters the whole order_line recordset on every call.
Since the onchange is triggered by any change to order_line, this noticeably slows down every modification of the lines on large orders even when the order contains no combo product at all.

_**Current behavior before PR:**_
For every order line, _onchange_order_line calls line._get_linked_lines(), and each call re-scans the entire order_line recordset with filtered(). The cost therefore grows with the total number of lines (regular lines included), so editing any line on a large order is sluggish.

_**Desired behavior after PR is merged:**_
The {line: linked_lines} mapping is computed in a single pass via the new method SaleOrderLine._get_linked_lines_by_line(), called once per onchange instead of once per line. 
The method _get_linked_lines() is kept as a thin single-record wrapper delegating to the batched method, preserving backward compatibility for external callers. Behavior is unchanged and only the performance is improved: the onchange now scales linearly with the number of order lines.

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

Forward-Port-Of: odoo/odoo#277620
Forward-Port-Of: odoo/odoo#277185

Issue :-

Steps to Reproducet: SaaS 19.3
- Create a new database Install the Sale module.
- Create a product set some On Hand quantity for that product (via Inventory adjustment).
- Create a Quotation using that product.
- Confirm the quotation (turning it into a Sales Order).
- Open the Forecasted Report for that product.

The Reserve / Unreserve button in the Forecasted Report not render.
<img width="1811" height="323" alt="image" src="https://github.com/user-attachments/assets/4093bddb-f332-4b84-a482-a6604ebcb318" />

Regression from the OWL3 rendering context migration ("[REF] stock,*: run rendering context migration script"), which rewrote the template call `displayReserve(line)` into `this.displayReserve(line)`. https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae and it comes in 19.2 onwards version.

The previous bare call compiled to `ctx['displayReserve'](...)`, so the method executed with `this` bound to that render context, which does own `line` and `line_index`. The lookups resolved by accident, not by design. as far as i have known.

With the explicit [`this.`](https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae#diff-c556e01f9a3ebdb27bb6599d12b74c7bb0a433177cc0e126365cb763a874d9f4R81) form required by OWL3, `this` is correctly the component instance, so `this.line` and `this.line_index` are undefined:

```py
  - `this.line_index - 1 >= 0`    -> NaN >= 0 -> false, the block is
                                     skipped and `splittedLine` stays true
  - `this.lines[this.line_index]` -> undefined
  - `.includes(undefined)`        -> false, so `isOnHand()` is false
```
<img width="1404" height="786" alt="image" src="https://github.com/user-attachments/assets/6d2cb88b-a695-4388-9b5e-3eac266f1877" />

`displayReserve()` therefore always returns a falsy value and the `t-if` never renders the button. `isOnHand(line)`, which the template also calls directly to render the reservable quantity, is broken for the same reason.

Root cause: 
loop variables produced by `t-foreach`/`t-as` live only on the template render context and must never be read off `this` in a component method. The previous code depended on OWL2 resolving a bare template call against that context, which OWL3 no longer does.

``` with the displayReserve(line) ```
<img width="1185" height="599" alt="image" src="https://github.com/user-attachments/assets/ed79f6db-f95c-437f-baf8-f65391df14e7" />

```with the this.displayReserve(line)```
<img width="1020" height="641" alt="image" src="https://github.com/user-attachments/assets/61103db5-7e0a-4362-9dd4-c2f47db2bd97" />

Fix: 
derive the values from the `line` argument the methods already receive, instead of reading them off `this`.
```py
  - `displayReserve()`: `const line_index = this.lines.indexOf(line)`, and
    use the `line` argument in place of `this.line`
  - `isOnHand()` / `isReconciled()`: test against `line` directly, since
    `this.lines[line_index] === line` inside the loop
```
The template is unchanged: the OWL3-compliant `this.displayReserve(line)` call stays as the migration left it, and no method signature changes.

``` with the current fix```
<img width="1100" height="480" alt="image" src="https://github.com/user-attachments/assets/39147abb-ba5e-42ae-84f5-3d7cbadda1e1" />

<img width="1879" height="304" alt="image" src="https://github.com/user-attachments/assets/fafd3d6a-7591-4dbd-a85c-8fb9de541dd8" />


OPW:- 6363290

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

**Problem:**
On a job position whose company is left empty ("Visible to all"), the Recruiter dropdown does not propose any user anymore: only the "Create" option is offered. The same happens on applicants without a company. Only saas-19.2 is affected: 19.0/19.1 still use the res.users-based recruiter field, and on saas-19.3 the company became mandatory on job positions.

**Steps to reproduce:**
1. Install Recruitment
2. Open a job position whose Company is "Visible to all" (e.g. any demo job position)
3. Edit the Recruiter field

**Current behavior:**
The dropdown shows no user, only the "Create" option.

**Expected behavior:**
The dropdown lists the recruiters of all companies, as it does (per company) when a company is set.

**Cause of the issue:**
Commit 05e22346050d replaced the res.users-based `user_id` recruiter field with the hr.employee-based `recruiter_id`, declared with `check_company=True`. For check_company fields, `_description_domain()` sends the client `company_id and [('company_id', 'in', [company_id, False])] or [('company_id', '=', False)]`. When the record has no company, the domain falls back to `[('company_id', '=', False)]`, and since `hr.employee.company_id` is required, no employee can ever match. This reintroduces the issue previously fixed by 5dfe494e62af for the old user_id field: the `allowed_user_ids` mechanism introduced there was dropped by the field replacement.

**Fix:**
`check_company=True` brings nothing to these models server-side (neither `hr.job` nor `hr.applicant` has `_check_company_auto`): its only effect is that client-side domain. Folding the company condition directly into the recruiter domain with `('company_id', '=?', company_id)` keeps the per-company filtering when a company is set and degrades to no filtering when it is not, mirroring what is already done for `interviewer_ids` on the job position. The domains become strings so the client keeps evaluating `company_id` per record.

opw-6290312

Forward-Port-Of: odoo/odoo#270529

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

Selecting an online media-library illustration for a product image (or any field using the media dialog) saved the wrong image, or failed with "Please try to reupload this image" or a "raw is undefined" crash.

Steps to reproduce
==================
1. Open a product and edit its image
2. In "Select a media", search a term (e.g. "new")
3. Click one of the online library illustrations

=> The wrong image is saved, or an error notification is shown

Root cause
==========
Library media results carry a media-library id, not a local ir.attachment id.
imageSave persists them as real attachments (save_library_media, run inside super.save) but then reads them back using the original media-library id. That id either collides with an unrelated local attachment, e.g. a type='url' demo record with no raw, hence the wrong image and the "reupload" warning or matches no record at all, so the read returns undefined and accessing .raw throws.

Fix
===
Use the ids of the attachments actually created by the render step, carried on the rendered <img> elements (dataset.attachmentId), instead of the media-library ids.

opw-6353273

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

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277425

**Steps to reproduce:**

- Create an attribute of type always, 2 values A and B for it
- The two values should have an extra price, like 100 for A and 150 for B
- Create an attribute of type dynamic, 2 values C and D for it
- C should have an extra price of 100 and 150 for D
- Make a product with both of those product, set the price to 100

2 possibilities:

- In the PoS, click the product, on the product popup, the price is 100
- This 100 is the product's price and does not change even if we change the values
- Order that product and buy it with variants A and C
- Click on the product again, the price is 300, which is correct
- When we click on D, the price is reset to 100, but should be 350

**Why the fix:**

When computing the popup's title, we try to get the current product based on the variants choices in the popup. If the product is found, we take that, because it means that it's already in the database.

https://github.com/odoo/odoo/blob/0d7f5058664b501779b833609468e535b34356bf/addons/point_of_sale/static/src/app/components/popups/product_configurator_popup/product_configurator_popup.js#L260

If we do not find it, we just take the product template, which does not contain the current extra prices, which is why we got a price of 100 in the exemple.

The product is not found because in the case of dynamic variants, the product is only created once it has been ordered at least once. Which means that for this newly created product, it is not yet in the database, so we take the product template instead of the product itself.

We now also add the extra price for a product if it is undefined, meaning it has not been found in the database yet.

We can't directly update the getter for the priceExtra, as it's also used to build the payload. As the rest of the code works fine with dynamic products with extra price the way it is sent now, we only change the title instead of changing the entire logic and computation.

opw-6326125

Forward-Port-Of: odoo/odoo#273411

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#277131
Forward-Port-Of: odoo/odoo#269100

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277425

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

Forward-Port-Of: odoo/odoo#277041
Forward-Port-Of: odoo/odoo#275391

### Issue before this commit:
Sending a TicketBAI invoice to a customer with a Spanish address and a VAT number starting with 'N' (Non-resident entity) resulted in a rejection with error B4_2000027. The XML incorrectly generated the national <DesgloseFactura> tag instead of the required <DesgloseTipoOperacion> tag.

### Steps to reproduce the issue:
1. Download Accounting, l10n_es and l10n_es_edi_tbai
2. Change name to ES Company into “NOMBRE APELLIDOUNO APELLIDODOS” (this is to make sure the certificate for Ticketbai works)
3. Go to Settings → Spain Localization → set Tax Agency for = Bizkaia
4. Change VAT number for customer Mulhacén Digital S.L. into N0011452J (must be a foreign entity ID)
5. Go to Settings > Technical > System Parameters and set the parameter 'l10n_es_edi_tbai.epigrafe' to 165360
6. Create a new invoice for that client and try to send it to TicketBAI
7. Error:  B4_1000002: Todos los registros incluidos en la petición son incorrectos. B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.

### Cause of the issue:
The _l10n_es_is_foreign() method evaluated these customers as domestic because their country was set to Spain and their VAT did not start with "ESN". It failed to recognize a standalone "N" prefix as a valid foreign identifier.
https://github.com/odoo/odoo/blob/75ae45861e2f417aa2b90bdb2b2869718e091c09/addons/l10n_es/models/res_partner.py#L7-L10


### Reason to introduce the fix:
Adding the 'N' prefix to the _l10n_es_is_foreign() check ensures the system correctly treats these entities as foreign for tax purposes. This generates the correct XML structure automatically, without forcing users to unnaturally prepend "ES" to a legally valid NIF.

opw-6326359

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

Forward-Port-Of: odoo/odoo#275231

Backport of : https://github.com/odoo/odoo/pull/269057 to  V18 
When an international customer selects an in-store pickup location, the
order's fiscal position changes to the fiscal position matching the pickup
warehouse. However, the order-line taxes and checkout summary are not
recomputed immediately.


**Steps to reproduce:**

1. Configure a French company and website.
2. Configure a product priced at 100  ( just an example , any price will do ) EUR excluding 20% French VAT.
3. Configure an export fiscal position removing VAT for Japan.
4. Configure an international delivery method.
5. Configure an in-store pickup method with a warehouse located in France.
6. Checkout using a Japanese delivery address.
7. Select the international delivery method.
8. Switch to pickup in store.

**Current behavior:**

- The order fiscal position changes to the French fiscal position.
- Product-line taxes and the checkout summary remain based on the export
  fiscal position.
- French VAT only appears later on the payment step.
- Switching back to international delivery can similarly leave stale totals.

**Expected behavior:**

- Selecting the French pickup location immediately applies French VAT.
- Switching back to international delivery immediately removes French VAT.
- Totals displayed during delivery selection match the payment-step totals.

**Cause:**

The Click & Collect flow explicitly recomputes `fiscal_position_id` when
selecting or leaving an in-store pickup location, but it does not recompute
the order-line taxes and prices.

Additionally, the pickup-location route does not return updated order-summary
values, so the checkout page cannot refresh its displayed totals.

**Solution:**

- Recompute taxes and prices when the in-store fiscal position changes.
- Restrict the recomputation to draft website orders.
- Return the updated order summary after selecting a pickup location.
- Refresh the checkout summary using the returned values.

**Tests cover:**

- Japanese delivery with export fiscal position and no VAT.
- Switching to a French pickup location immediately applying 20% VAT.
- Switching back to international delivery removing VAT.
- Delivery-step totals matching payment-step recomputation.
- Pickup-location route returning updated summary values.

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

Forward-Port-Of: odoo/odoo#276201
Forward-Port-Of: odoo/odoo#269086

This PR introduces support for electronic e-Resguardos for Uruguay, fully compliant with DGI regulations and integrated into the existing electronic invoicing flow via Uruware.

The implementation is based on the existing withholding framework from Ecuador, with references to Argentina’s approach, and includes the necessary adaptations to meet Uruguayan legal and functional requirements.

Key features included in this PR:

- Out-of-the-box availability: once the module is installed, users can create e-Resguardos without additional activation steps.
- Base configuration for withholdings:
  - Common withholding taxes (VAT and IRPF).
  - New field for DGI Withholding Code on taxes.
  - Configurable destination and default withholding accounts.
- Two main functional flows:
  - Creation of e-Resguardos from a single vendor bill.
  - Creation of e-Resguardos with multiple or no invoice references, including proper reference handling in XML depending on payment context.
- Automatic calculations of withheld amounts based on selected tax and base.
- XML generation and submission through the existing Uruware connection, including reception of validated XML (CAE) and PDF with electronic stamp.
- Compliance with the 10,000 UI threshold, enabling users to generate e-Resguardos when required by regulation.
- Storage and visualization of XML and PDF directly in Odoo, with printing support.
- Comprehensive testing coverage: single and multi-invoice cases, without reference, threshold logic, XML validation, and PDF rendering.

This PR lays the foundation for future extensions to additional e-Resguardo types while delivering a complete and compliant solution for the most common withholding scenarios in Uruguay.

Task: 4557347

Previously, when a report was loading if a variant was selected, it would display the first one when it loaded and display the second one when it loaded.

With this, we wont show the first one as we are waiting for the new one.

To reproduce:
- load the Demo data on the demo company
- Add time.sleep(5) in _get_lines
- load the Generic Tax report and wait for it to load
- click on the Group by: Account > Tax and wait for 3s
- click on the Group by: Tax > Account
- Watch the Account > Tax load and still being displayed for 3s while the Tax > Account variant is loading.

The loading of the report contains 2 steps:
- Loading the options of the report
- Loading the content of the report itself

The options are used to update the bar at the top of the screen with the filters, such as date or horizontal_split.
Since some of those filters dont need to call again for the options, we will store them in a map loadingOptionsFunctions, for them to be called when the options have been fetched.
If they are clicked when the data of the report is loading, we can directly updated the options since they dont need to update the value of the lines.

Some need to update the lines like rounding_unit, however since the call to format_column_values_from_client is faster than querying again the line,
We check if the currency changed while loading the report and if it did, we format the column values.

Following those changes, a lot of async/await were rendered useless since we are not waiting for the click of the filter before the user can click on another one.
We are able to remove them and when changing the value of an option with _updateOption or updateOption, ... they will return the promise of the reloading of the report which can be awaited when necessary.

Issue Before This Commit:
=============================
The workorder planning Gantt view only declared some fields inside the popover element. As a result, they were not fetched with the Gantt records, even though Gantt decorations also used them.

Steps to Reproduce:
===================
- Install the **mrp_workorder** module.
- Enable the **Work Orders** option in **Manufacturing → Configuration → Settings**.
- Create and plan a MO with at least one work order.
- Open the work order planning view from the **Planning** menu.
- Observe the following error: 
An `EvalError` is raised: `Name 'has_conflicts' is not defined.`

Cause of the Issue:
=============================
In this [PR](https://github.com/odoo/enterprise/pull/123693), the variables were moved inside the popover, which caused the Gantt view to lose access to them.

After This Commit:
=============================
These fields have been restored as top-level Gantt fields, ensuring they are loaded with the record data and accessible wherever they are needed.

***Issue:***
Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again.

That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one.

***Fix:***
Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents.

***Steps to reproduce:***
1. Open the Documents app
2. Switch to the list view
3. Tick the checkboxes of two documents
4. Click the Actions button next to the "2 selected" box

=> the Actions dropdown does not open

Ticket [link](https://www.odoo.com/odoo/project.task/6365618)

opw-6365618

Forward-Port-Of: odoo/enterprise#124238
Forward-Port-Of: odoo/enterprise#123575

Version - 19.0

Steps to reproduce(runbot):
- Install `l10n_au_hr_payroll`
- Go to Payroll -> Configuration -> Super Accounts
- Create a Super Account by filling all the required fields
- You will encounter the issue
**TraceBack:**
```
('hr.menu_hr_employee_payroll', 485, 'Employees > Employees', 756):
 Traceback (most recent call last):
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 346, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 537, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 570, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6688, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1744, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1915, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 484, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4954, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/19.0/l10n_au_hr_payroll/models/hr_employee.py", line 118, in _compute_proportion_warnings
    proportions[emp.id] * 100,
 KeyError: 4
```
Issue:
During the refactoring from `read_group()` to `_read_group()`, the `proportions` dictionary became keyed by `hr.employee` records instead of employee IDs. While the condition was updated to use `proportions.get(emp)`, the warning message still accessed the dictionary using `proportions[emp.id]`, resulting in a `KeyError`.

Fix:
Use the employee record consistently when accessing the `proportions` dictionary after switching to `_read_group()`.

Task ID - 6390373
Refrence:
https://github.com/odoo/enterprise/pull/72217/changes#diff-8ae3564d54e47eec919ef273d44f6276d8c6df60e21c5c8c8f7292b1c38cf541R460

Forward-Port-Of: odoo/enterprise#124478

In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started.

Case 1:
- Have website A and website B
- Create an appointment page website A
- Log in via website B
- As public user, make an appointment in Website A
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url.
This parameter is then used as fallback when we need to retrieve the base url without an active record

Case 2:
- Have website A and website B
- Create an event and assign it to website B
- As public user, access the event and register to it
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event.
This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A)

Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf

opw-4146760
opw-4336369

Forward-Port-Of: odoo/enterprise#124714
Forward-Port-Of: odoo/enterprise#122669

**Steps to reproduce:**
* Install **l10n_fr_pdp** module.
* Create two companies: one French (with PDP activated) and one in another country (e.g. Belgium).
* Create a customer invoice in the **non-French company** for a **French customer**.
* Open **Send & Print** and try to send via **email**.

**Observed behavior:**
* Sending fails with: `Errors occurred while creating the EDI document (format: France UBL 2.1 E-Invoicing Format):` `- The following partner's SIREN or SIRET is missing: <BE company name>` `- The following partner's PDP identifier is missing: <BE company name>`

**Cause:**
* `_get_suggested_invoice_edi_format()` on `res.partner` returned `'ubl_21_fr'` for any French B2B partner regardless of which company was sending the invoice.
* This caused `ubl_21_fr` to be stored as the partner's `invoice_edi_format` and selected at send time, even when the sending company has no PDP registration.
* The `ubl_21_fr` XML builder then validates that **both** supplier and customer have French PDP credentials (EAS 0225, SIREN/SIRET), which the non-French company cannot satisfy.

**Fix:**
* In `_get_suggested_invoice_edi_format()`, add a guard on `self.env.company._get_peppol_proxy_type() == 'pdp'` so that `'ubl_21_fr'` is only suggested when the active company is a PDP-registered French company.

**Note:**
* No test added — reproducing this bug requires two localization modules to be installed simultaneously (e.g. `l10n_fr_pdp` + `l10n_be`), which is not supported in the standard test framework.

opw-6392253

**Steps to produce:**
- Install the `sale_stock` and `sale_management` modules.
- Create a product with the Invoicing Policy set to `Delivered quantities`.
- Create a Sales Order for 5 units of the product, confirm it, and validate the delivery.
- Create and post the customer invoice for the 5 units (SO status is now Fully Invoiced).
- Return 3 units from the validated delivery, click on the `Return for Exchange` option, and validate the transfer.
- Observe the Sales Order's invoice status from the list view.

**Issue:**
- The Sales Order status erroneously switches to `To Invoice` instead of remaining `Fully Invoiced`.

**Root cause:**
- When a return picking is validated with return exchange, the `qty_delivered` on the `sale.order.line` drops immediately. This causes `qty_to_invoice` (`qty_delivered - qty_invoiced`) to become negative from [1].
- And then from [2], the invoice status is set as `To invoice`.

**Solution:**
- Adjust the existing `_compute_invoice_status` override in `sale_stock` to account for pending replacement moves generated during exchange returns. If the replacement quantity offsets the negative `qty_to_invoice`, keep the order `Fully Invoiced` instead of marking it `To Invoice`.

[1]https://github.com/odoo/odoo/blob/b0fc5668990c42f129432dd7eeeb24a042d4b153/addons/sale/models/sale_order_line.py#L1006
[2]https://github.com/odoo/odoo/blob/b0fc5668990c42f129432dd7eeeb24a042d4b153/addons/sale/models/sale_order_line.py#L1041

**opw-6299909**

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

Clicking the translate button saves the form's root record before opening the translation dialog, since https://github.com/odoo/odoo/commit/9da52919a03dbcee5209430918195158c0652099. A record opened in an x2many form dialog keeps its changes for itself until the dialog is saved, see https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/web/static/src/model/relational_model/static_list.js#L193. Its pending changes are not part of the root record changes, so saving the root sends nothing to the server, and the translation dialog then shows the stored terms instead of the current content, or no terms at all when the stored value is empty.

The fix changes openTranslationDialog in translation_button.js, the place that decides which record to save. When the record keeps its changes for itself (record._noUpdateParent), the record is saved directly, like the button did before the commit above. The root record is still saved in the other cases, so the editable list case that commit fixed keeps working.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app, open a survey and click a question in the Questions tab
3. In the Description tab, change the description
4. Click the EN button on the description field

=> the translation dialog shows the terms of the previous description, not the current one

Ticket [link](https://www.odoo.com/odoo/project.task/6237291)
opw-6237291

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

Forward-Port-Of: odoo/odoo#276774

When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted.

Wrap the search_count call in _updateMatchingRecordsCount (property_definition.js) in a try/catch and show no count when it fails. This is the only place the editor counts matching records, so guarding it here handles a bad domain from any source, the field selector or the code editor. The field selector still shows its warning on the invalid path, so the user can fix or delete the property.

Steps to reproduce:
1. On a model that has a Properties field, add a Many2one property and set its Model to a model that itself has a Properties field.
2. Open the property Domain and click New Rule.
3. In the field selector pick the Properties entry, then close the selector.

=> An error dialog appears and the property can no longer be edited or deleted.

Ticket [link](https://www.odoo.com/odoo/project.task/6101311)
opw-6101311