Currently, requests from the PoS UI are sent without any timeout, which can lead to indefinite waiting when the system is connected to a network but lacks internet access.

Examples:
- `sync_from_ui` can take more than 2 minutes to fail.
- Font CDN requests during receipt printing can take over 4 minutes to fail.
- In some cases, this causes receipt printing failure as well, even after several minutes (4-5 min) of delay.

This commit introduces a timeout for PoS UI requests to prevent such delays and improve responsiveness.

Additionally, font declarations are extracted from `web` into `point_of_sale`, and only the required fonts are included. This avoids unnecessary requests to missing CDN resources.

Additionally, this PR backports the following commits required to support this fix:
- https://github.com/odoo/odoo/pull/215130
- https://github.com/odoo/odoo/pull/220954
  Ensures the system continuously checks network connectivity and resumes synchronization once the connection is restored.
- https://github.com/odoo/odoo/pull/225743
  Prevents receipt printing from being blocked by logo loading issues and ensures the logo is displayed gracefully in such scenarios.

Task-6053404

| Font CDN request delay (~ 4 min)                   | `sync_from_ui` long request (> 2 min)            |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| <img width="400" src="https://github.com/user-attachments/assets/8ea8b3e4-7ffe-44bf-a4d0-7975f43a8f68" /> | <img width="400" src="https://github.com/user-attachments/assets/5f899cab-b022-4ed2-aa82-12e54ea34ea7" /> |

### Issue:
When invoicing a sale order for a kit, components tracked by quantity that are archived are excluded from the Cost of Goods Sold (COGS) calculation

As a result, the journal items for "Expenses" and "Stock Interim (Delivered)" are undervalued on the invoice, creating a mismatch with the inventory valuation which correctly includes the archived components' costs Odoo natively allows the delivery and usage of
archived components when they are part of a BoM

### Cause:
The Bill of Materials (BoM) explosion correctly bypasses the active check using `with_context(active_test=False)`
However, during the invoice posting, `_stock_account_get_anglo_saxon_price_unit()` filters the kit's components using a standard `search()`, but without disabling the active test
Consequently, archived components tracked by quantity are ignored when computing the final anglo-saxon price unit

### To reproduce the issue:
- Install `account_accountant`, `sale_management` and `mrp`
- Create a product category PC (Inventory Valuation: Automated)
- Create 3 Products:
  - Kit (Tracked: Quantity, Product Category: PC)
  - Kit_Comp01 (Tracked: Quantity, Product Category: PC, Cost: 10$)
  - Kit_Comp02  (Tracked: Quantity, Product Category: PC, Cost: 20$)
- Set Kit_Comp01 and Kit_Comp02 on hand's quantity to 1
- Create a Bill of Materials (Product: Kit, Type: Kit, Components: 1x Kit_Comp01, 1x Kit_Comp02)
- Archive Kit_Comp02
- Create and Confirm a Sale Order for 1x Kit
- Process the related delivery
- Create and Post the Invoice
- Check the Journal Items tab Before the fix, the lines `Expenses` and `Stock Interim (Delivered)` are 10$ instead of 30$

opw-6204621

**Steps to reproduce:**
* Install **l10n_mx_edi**.
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the
  custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new
  invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

**Observed behavior:**
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

**Cause:**
* `_get_invoice_report_filename` in `l10n_mx_edi` unconditionally returned the CFDI filename whenever `l10n_mx_edi_is_cfdi_needed` was `True`, ignoring the `invoice_report` context key.
* `account_move_send` sets `invoice_report` to the extra mail template when requesting the filename for dynamic report attachments, expecting the method to delegate to `super()` and evaluate the template's `print_report_name`.  The MX override never reached that branch.

**Fix:**
* Check for the `invoice_report` context key before applying the CFDI filename logic.  When it is present (i.e. a custom/extra report is requesting its filename), fall through to `super()` so the template's `print_report_name` is used correctly.

opw-6228268

**Problem:**
partial quantities in a dropship picking 
is not taken into account for the svl quantity
(it's always the full initial quantity)

**Steps to reproduce:**
- create a storable product with dropship route
- set the category as avco auto
- set a vendor in the purchase tab with a price of 10
- confirm a SO for a quantity of 2
- confirm the related PO with a unit price of 10
- on the dropship picking change the quantity to 1
- validate without backorder
- click on the valuation smart button

**Current behavior:**
- the svls have quantities of 2 and -2
- the related amls have debit/credit of 20

**Expected behavior:**
- the svls should have quantities of 1 and -1
- the related amls should have debit/credit of 10

**Cause of the issue:**
when creating the svls we use the move's product_qty
instead of its quantity
https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290

**fix:**
product_qty is expressed in the uom of the product
and quantity in the uom of the move so we need 
to add a uom conversion to the fix

opw-6113031

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Steps to reproduce:
===================
1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates
2. Open /customers
3. Open the map and zoom in a few times

=> stale blue cluster bubbles remain on the map

Cause:
======
On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level.

`ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map,
https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation.

Solution:
=========
Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon.

opw-6128531

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

Avoid traceback when there is special hidden characters on the VAT numer, compact() method from stdnum does not process it.

We use regex to get only the number part for all the doc types

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

1. Create new contact
2. add cuit value (in the vat field). This one is copy from an external program with special hidden characteres

### Current behavior before PR:

There is a traceback and the user can not create the contact

```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/addons/l10n_ar/models/res_partner.py", line 123, in _get_id_number_sanitize
res = int(stdnum.ar.cuit.compact(self.vat))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '\u206030717808599'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30061:19)
at XMLHttpRequest.<anonymous> (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30124:27)
```
### Desired behavior after PR is merged:

Will let us to create the contact and validate the cuit no matter if it has or not an special character



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

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#120967

### Issue
`l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises:

```
TypeError: Model 'certificate.certificate' does not exist in registry.
```

### Cause
`models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`.

### Notes
- Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op.
- Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first.

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Description of the issue/feature this PR addresses:

When an invoice has advance payment lines that exactly cancel the product lines (net taxable base = 0 per VAT aliquot), floating-point accumulation
in `_aggregate_base_lines_aggregated_values` leaves a tiny residual
(e.g. ~1e-12). This residual is truthy in Python, so `_get_vat()` adds
the aliquot entry to the result even though both `BaseImp` and `Importe`
round to `0.00`. The AFIP WSFE web service receives a non-null `Iva`
block with all-zero amounts instead of `null`.

## Steps to reproduce

1. Create an invoice with one or more product lines (IVA 21%, for example).
2. Apply an advance payment that fully cancels those lines.
3. Confirm the invoice and inspect the generated WSFE XML preview.
4. **Before fix:** `Iva` contains `{'AlicIva': [{'Id': '4', 'BaseImp': '0.00', 'Importe': '0.00'}]}`.
5. **After fix:** `Iva` is `null`.

## Root cause

`_get_vat()` checked the raw (unrounded) aggregated float values in the
filter condition:

```python
if ... and (values['base_amount_currency'] or values['tax_amount_currency']):




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

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

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

Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up.

## Benchmarks
|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|6,262       |0.13s      |68            |0.12s     |68           |
|68,882      |0.60s      |112           |0.58s     |109          |
|432,317     |5.49s      |398           |3.68s     |309          |
|757,702     |15.33s     |1,141         |5.79s     |599          |

[opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)