Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf)
and deduplicating overlaps

* Current Situation: Currently real duration is total duration of each
time tracking which
is not consistent with the time that use to calculate the cost for
valuation , see https://github.com/odoo/odoo/pull/205154 .The real
duration of a work order was incorrectly summing all time tracking
entries regardless of their loss type, and using simple addition which
double-counts overlapping intervals.

* Solution:
- Filter time entries to only 'productive' and 'performance' loss types,
  excluding 'availability' and 'quality' as they represent
downtime/blocking
  time, not actual work duration.
- Pool all productive and performance entries into a single Intervals
call
  so that overlaps across both types are merged in one pass.

Note: the enterprise17 implementation groups time entries by loss_type
into
separate buckets before calling Intervals, which means overlaps between
'productive' and 'performance' entries are not merged and get
double-counted.
Pooling both types together before the Intervals call avoids this.

* This also fix:
- Fix _set_duration to ensure newly created time entries start after the
  latest existing entry's end date. Without this, calling _set_duration
  twice in quick succession (e.g. in tests) produces two entries with
  overlapping timestamps, which Intervals correctly merges into one,
  causing the computed duration to be half the expected value.




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

Forward-Port-Of: odoo/odoo#248381

**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#121512
Forward-Port-Of: odoo/enterprise#120967

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

Forward-Port-Of: odoo/odoo#271596
Forward-Port-Of: odoo/odoo#263029

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

Forward-Port-Of: odoo/odoo#270733

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

Forward-Port-Of: odoo/odoo#271496