When finishing a repair order a stock valuation entry is created for the
product used. If you then make a quotation and invoice it another
stock valuation entry would be created for the same product.

Steps to reproduce:
-------------------
* Create a category using FIFO and real time valuation
* Create a product using this category and set it's cost to 5€
* Set some on hand quantity for the product
* Create a repair order and add the product with the "Add" option
* Finish the repair order
> Observation: At this point you should have a valuation entry in the
  accouting app
* From the repair order create a quotation and invoice it
> Obesrvation: If you check the accounting entries again you will see
  a second valuation entry

Why the fix:
------------
When checking if the line is eligible for valuation we make sure that if
it is linked to a repair order, this repair order should not have any
accounting entries linked to it.

opw-5429996

Forward-Port-Of: odoo/odoo#254468

Report edits could be applied on shared layouts such as web.basic_layout instead of the report-specific document view.

This caused Studio customization diffs to affect unrelated reports and could also lead to rendering errors when report-specific fields were evaluated in a different report context.

The issue occurred because content was inserted directly into the shared layout article section instead of the nested report document view.

Steps to reproduce:
1. Open Studio on any module and create or edit a report.
2. Select any of the External, Minimal, or Blank report types.
3. Add content to the report body and save the report.
4. Open another module and create a report using the same report type.
5. Observe that the previous customization is already present.

Before this fix, the generated diff could inherit from web.basic_layout. After this fix, body edits are kept inside the report-specific document view.

Related Ticket:
opw-6245485

Forward-Port-Of: odoo/enterprise#118880

Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120175
Forward-Port-Of: odoo/enterprise#112859

Steps to reproduce:
-------------------
1. Install Fleet with demo data.
2. Create a contract for a vehicle (A) with a recurring cost of 1000
 and "Monthly" frequency.
3. Go to Reporting > Costs and verify the monthly cost
 (it shows 1000).
4. Create another contract for the same vehicle (A) with a
 recurring cost of 50 and "Monthly" frequency.
5. Check the monthly cost again.

Issue:
------
The reported cost is incorrect. Instead of 1050 (1000 + 50), it shows 2100.

Cause:
------
The query uses multiple LEFT JOINs on the contract table, including:
https://github.com/odoo/odoo/blob/9ca36dbe53692309bac84329de3b54a1c510cce0/addons/fleet/report/fleet_report.py#L103

These joins overlap and produce duplicate rows for the same
vehicle and month, which results in inflated cost totals.

Solution:
---------
Replace the multiple LEFT JOINs with a single LATERAL join.
This ensures the contract table is processed once per vehicle per month and
avoids duplication, resulting in correct totals.

**Before:**
<img width="940" height="609" alt="image" src="https://github.com/user-attachments/assets/e5b3e747-1135-4674-97c9-4e4fd9986dfd" />

**After:**
<img width="1053" height="590" alt="image" src="https://github.com/user-attachments/assets/f0df3819-07fb-4de5-aab3-5b4c6f10d213" />



opw-6024132





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

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120011
Forward-Port-Of: odoo/enterprise#115256

\* = website, website_crm

### Issue:
When a page is created either through the configurator or from an
existing page template, block-level snippets do not display the correct
title in the builder sidebar. Instead, "Block" is shown for all
snippets.

### Steps to Reproduce:

- **Configurator:**
  1. Install the website module or create a new website from Settings.
  2. Complete all configurator steps. Do not use "Skip and start from
     scratch".

- **Page template:**
  1. Open the website and click the "New" button in the systray.
  2. Click on "Page" and choose any template other than a blank page.

### Observed behavior:
The builder sidebar shows "Block" in the option container for all
snippets instead of their actual names.

### Reason:
Previously, just before the builder was opened, the `data-name`
attribute was injected through `_computeSnippetTemplates()` for any
snippet that did not already have it. This behavior was lost after the
plugin refactoring.

### Fix:
As before, we now inject the `data-name` attribute during builder setup
for snippets that do not already have it.

task-[6087348](https://www.odoo.com/odoo/all-tasks/6087348)

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

Forward-Port-Of: odoo/odoo#268637
Forward-Port-Of: odoo/odoo#259893

[FIX] ai: scope AI_ADJUST_SEARCH bus event to originating session
The AI_ADJUST_SEARCH handler did not check aiSessionIdentifier, so any
browser tab subscribed to the bus would apply the AI's resulting search
to its current view. When the view's model lacked a field referenced in
the response (e.g. an "Active or Queue" filter on stage_id leaking from
a project.task chat into a timesheet view), the view raised a KeyError.
Align it with the four AI_OPEN_MENU_* handlers, which already drop events
from other sessions since https://github.com/odoo/enterprise/commit/d85e17d9ccf70f9cfd51c7d6b2a5b52510807484.

Steps to reproduce:
- Run Odoo with the crm and contacts modules installed
- Open two tabs:
    - Tab 1: navigate to CRM and ensure you are in List view
    - Tab 2: navigate to Contacts and ensure you are also in List view
- In Tab 1 (CRM), open the Ask AI chat and type "Switch to Kanban view"
- CRM switches to Kanban view as expected
- Bug: Tab 2 (Contacts) also switches to Kanban view along with Tab 1,
  even though you did not interact with it

Forward-Port-Of: odoo/enterprise#118237

Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion.

However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks.

This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load.

Steps to reproduce:
- Use Firefox (or a Gecko-based browser)
- Open a new mailing
- Select the Events theme and make an edit (add a space...)
- Save the mailing
- Wait for 23 seconds

The bug may be non-deterministic.

Fix:

Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs.

task-6293998

Co-authored-by: Damien Abeloos <abd@odoo.com>

Forward-Port-Of: odoo/odoo#269324

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Self-order showed one price on product cards / product page and another after adding to the order, when a preset fiscal position (e.g. take-out) changed taxes. The UI used template-only pricing and sometimes skipped fiscal position on tax computation.

Steps to reproduce:
-------------------
* Create a fiscal Position (e.g. takeout)
* Create a Taxe for that Fiscal Positions replacing the default Taxe (e.g. 0%)
* Create a pricelist with a formula increasing the price by the same % as default Taxe (e.g. 15%)
* Enable Self-Ordering for a Restaurant
* In the takeout Presets, set our Pricelist and Fiscal Positions
* Open the Mobile Menu of the Restaurant and add a product that has variants (e.g Pizza VG)

> Observation:
Price on product selection is different from price in cart

Why the fix:
------------
We now make self-order use the same rules as an actual order: default variant for template-only display, pricelist from pos.order first (what setPreset and the session already maintain), fiscal position from the order or the preset everywhere taxes are derived, and correct tax inputs on the product page (price, pricelist, fiscalPosition, variant).
Order line tax preparation now uses that same order-or-preset fiscal position, so remapped taxes apply to lines the same way they apply to the prices shown while browsing.

opw-6120097

Forward-Port-Of: odoo/odoo#261535

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#113133

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#119164
Forward-Port-Of: odoo/enterprise#109032

Currently when using a stripe terminal and the tips after payment feature the transaction is marked as cancelled while the transaction is marked as uncapured on stripe.

Steps to reproduce:
-------------------
* Set up terminal payment (using SIMULATOR works)
* Enable tips after payment feature
* Open restaurant
* Make an order
* Go to payment screen, select stripe
* Scan card (with simulator everything is automatic)
> Payment line is marked as cancelled

Why the fix:
------------
After this commit https://github.com/odoo/odoo/commit/c27deda808660dde89305d574b6d662157d99d16 if `captureAfterPayment` does not return true the status of the payment line will be set to `retry`.

However when pos_restaurant_stripe is also installed `captureAfterPayment` can return `undefined` when tips after payment is enabled. https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/pos_restaurant_stripe/static/src/overrides/models/payment_stripe.js#L5-L11

In this case we want to capture later and we expect the pethod to not return anything. In this case we don't want to change the status of the payment line.

opw-6223838

Forward-Port-Of: odoo/odoo#268802

Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

Forward-Port-Of: odoo/odoo#268886
Forward-Port-Of: odoo/odoo#267479

# How to reproduce
- Activate Accounting & l10n_be modules with demo data
- Use "BE Company CoA"
- Go to Settings > Users & Companies > Companies > "BE Company CoA" > Branches
- Create new branch company
- Go to Settings and Enable PEPPOL, then save
- Still in Settings, click on "Activate Electronic Invoicing" > Activate Peppol (demo)
- Now use the branch company
- In Settings, click on "Activate Electronic Invoicing", select "Send from parent company" > Activate Peppol (demo)
- Go to Settings > Users & Companies > Users > any user (can be the current one)
- Remove the user's access to "BE Company CoA"
- Log in as that user if it is not the current one
- Create a partner that can receive PEPPOL invoices :
	- Country : Belgium
	- Invoice sending : by Peppol
	- eInvoice format : EU Standard (Peppol Bis 3.0)
	- VAT : BE0477472701
	- Peppol id : Belgian Company Registry
- Create an invoice for that partner
- Click on Confirm, then Send

# The problem
You cannot select the "by Peppol" sending method. It has the "(no access)" error attached to it.

# Cause
The sending method's enable state is computed by : https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/account_peppol/wizard/account_move_send_wizard.py#L13

This method runs multiple check to see if the invoice can be send via peppol and one of them calls `_have_unauthorized_peppol_parent_company()` : https://github.com/odoo/odoo/blame/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/account_peppol/models/res_company.py#L136-L143

This checks that the current user has access to the parent company, which is our exact use case. This specific flow was indeed blocked by the task that introduced branch company PEPPOL invoicing : https://github.com/odoo/odoo/commit/6dd8bc34ba79c14408dc271c19ca7afb0f85fa44

The reason behind this block is in part explained by this comment : https://github.com/odoo/odoo/pull/216864#discussion_r2205047170

But after talking with the Peppol PO, this flow should be allowed

# Proposed solution
Entirely remove the `_have_unauthorized_peppol_parent_company()` check. 
After testing, it does not seem we have any access issues to worry about.

opw-6080867

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

Forward-Port-Of: odoo/odoo#262523

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

Forward-Port-Of: odoo/odoo#265583
Forward-Port-Of: odoo/odoo#248626

Steps to reproduce
1. With a Mexican POS configured, create a POS order and sign a Global Invoice for it.
2. Open a new session and partially return the order; close the session.
3. On the original order, cancel the Global Invoice through the CFDI page.
4. Try to create a new Global Invoice for the original order.

Issue
The wizard raises "Orders <REFUND-NAME> are already sent or not eligible for CFDI."

Validating the refund auto-signs an `invoice_sent` CFDI on the refund pos.order because its parent is `global_sent`, see `_l10n_mx_edi_check_autogenerate_cfdi_refund` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L98. Cancelling the GI only flips its own document to `ginvoice_cancel`; the refund's `invoice_sent` doc stays untouched, so the refund's computed `l10n_mx_edi_cfdi_state` stays `'sent'`. The chain check in `_l10n_mx_edi_check_orders_for_global_invoice` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L184 then rejects the refund as already sent and the new GI cannot be created.

opw-6181136

Forward-Port-Of: odoo/enterprise#120100
Forward-Port-Of: odoo/enterprise#117211

When reloading a chart of accounts, `_pre_reload_data` resolves an account via its xmlid and then evaluates:
```py
    re.match(f'^{values["code"]}0*$', account.code)
```
`account.code` is a non-stored computed field that reads from the company-dependent field `code_store`. If the resolved account has no `code_store` entry for the target company (e.g. the account was originally set up under a different company but its xmlid was prefixed with the current company id), `_compute_code` returns False instead of a string, causing a TypeError in re.match.
```py
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 442, in _pre_reload_data
    if not account or not re.match(f'^{values["code"]}0*$', account.code):
  File "/usr/lib/python3.10/re.py", line 190, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object
```
```sql
apan_4342860=> SELECT
    aa.id,
    aa.code_store,
    imd.module,
    imd.name
FROM account_account aa
JOIN ir_model_data imd
    ON imd.res_id = aa.id
   AND imd.model = 'account.account'
WHERE aa.id = 1056;
  id  |   code_store    | module  |      name
------+-----------------+---------+-----------------
 1056 | {"2": "510500"} | account | 1_co_puc_510500
(1 row)
```

This situation arises when a customer moves or reassigns an account between companies but the xmlid retains the original company prefix.

**Fix:**
After resolving the account via xmlid, check whether it actually belongs to the target company using filtered_domain with _check_company_domain. If it does not pass the check, unlink the stale ir.model.data entry and treat the account as not found, allowing the reload to re-establish the correct xmlid linkage via the code-based lookup that follows.

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

Forward-Port-Of: odoo/odoo#269291

When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the
expected quantity=qty_original and discount=100%.

This happened because the line-level branching in
`_import_ubl_invoice_line_add_price_unit_quantity_discount` relied on the truthiness of `line_extension_amount` to detect whether the `LineExtensionAmount` node was present in the XML. a line with a genuine `<cbc:LineExtensionAmount>0</...>` was indistinguishable from a line where the node was missing, and fell
through to the fallback branch intended for incomplete XML. That fallback reconstructs the quantity from `<cbc:BaseQuantity>`, ignoring `<cbc:InvoicedQuantity>`, and then computes the discount percentage against the wrong denominator.

a `LineExtensionAmount` of 0 is the only legal way to express a fully discounted line, so this case must be distinguished from the node being absent.

the fix is simply checking if the line exist not if its True

opw-6176349

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

Forward-Port-Of: odoo/odoo#265261

## Issue
When using the browser's dark mode, non-mandatory text fields in sign documents appear with a dark background, which does not match the aesthetic of the rest of the page.

## Steps to reproduce
1. Set your browser's theme to a dark theme (in Chrome, go to Settings > Appearance > Theme, chose a theme from the dark options)
2. Install Sign (`sign`)
3. Open a Sign template and add 3 Text fields:
    - Mandatory
    - Non-mandatory
    - Read-only (for comparison)
4. Click *Sign Now*
5. **The non-mandatory text field has a dark background.**

## Cause
Since a [PDF.js update](https://github.com/mozilla/pdf.js/commit/ae1cbc6a9ecc738d6777830488ad5481b97338bc), the `light dark` color-theme was added to `:root`. This means that the element will react to the settings of the browser and adapt its background and text color. In this case, there's no other `background-color` provided to mandatory fields, resulting in them using the dark color of the browser theme.

## Fix
We make the default background of text fields transparent then we update the selector of `.o_sign_sign_item_required` to prevent their `background-color` from being overwritten by that new transparent background.

|            | Before | After |
|------------|--------|-------|
| **Light mode** |    <img width="211" height="99" alt="6213059-before-light" src="https://github.com/user-attachments/assets/c4c70394-c7c2-4dbf-92b9-c1362d1cf9c8" />    |   <img width="207" height="89" alt="6213059-after-light" src="https://github.com/user-attachments/assets/63142be5-9f7d-4d5d-94e8-ef9428e1b778" />    |
| **Dark mode**  |    <img width="220" height="95" alt="6213059-before-dark" src="https://github.com/user-attachments/assets/19149c3d-511e-407c-821e-f318f373368a" />    |    <img width="210" height="103" alt="6213059-after-dark" src="https://github.com/user-attachments/assets/0b412d4f-061f-41b3-aae9-569b9a8219dc" />   |

opw-6213059

Steps to reproduce
1. Configure a Polish company with KSeF enabled.
2. Create a customer invoice using a tax tagged with K_21 (0% EU G, intra-Community supply of goods), K_12 (0% EU S, services taxed in the buyer's EU country) or Triangular Sale.
3. Send the invoice to KSeF and download the generated FA(3) XML.

Issue
The Podmiot1 (seller) block in the rendered FA(3) XML omits the PrefiksPodatnika element, see https://github.com/odoo/odoo/blob/89219a843545d8bb0cad6ea806a1167cee6289da/addons/l10n_pl_edi/data/fa3_template.xml#L34-L42. According to the official Ministry of Finance documentation (https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf, page 11), this conditional field must carry the value "PL" when the invoice documents:
- the intra-Community supply of goods,
- the provision of services referred to in Article 100 sec. 1 item 1 of the Act for EU VAT taxpayers,
- the supply carried out under a simplified triangular transaction by the second taxpayer (Article 135 sec. 1 item 4 (b) and (c)). The XSD marks the element as optional (minOccurs="0", fixed="PL") so KSeF accepts the XML, but the seller's tax reporting is still legally non-compliant for the three cases above, and the field is missing from the KSeF PDF viewer rendering.

opw-6213178

Forward-Port-Of: odoo/odoo#264659

**Steps to reproduce:**
1. Install l10n_mx_hr_payroll.
2. Create an employee with a contract date over 35 years ago (e.g., 1985).
3. Create a payslip for this employee.
4. Click on "Compute Sheet".

```Error: KeyError(36) while evaluating```

**Cause:**
The rule parameter [rule_parameter_holiday_table](https://github.com/odoo/enterprise/blob/c02c4571bb7db7197b07539ba390d4d20fdce9fe/l10n_mx_hr_payroll/data/hr_rule_parameters_data.xml#L722-L758) defines values
only up to 35 years. Seniority exceeding this range causes a KeyError.

**Solution:**
Extended the `rule_parameter_holiday_2024` table from 35 to 60 years,
following the Mexican Federal Labor Law (LFT) reform formula
(+2 days every 5-year milestone from year 6 onwards).

**NOTE:**(Alternative approach)
```python
@staticmethod
def _get_mx_holiday_days(years_worked):
    if years_worked <= 0:
        return 0
    if years_worked <= 5:
        return 12 + (years_worked - 1) * 2
    five_year_periods = (years_worked - 6) // 5
    return 22 + five_year_periods * 2
    
  ```
This approach removes the need for XML data maintenance and handles
all future seniority values mathematically without any cap issues.
  
  
opw-6090590

Forward-Port-Of: odoo/enterprise#113536

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

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

Forward-Port-Of: odoo/odoo#268675
Forward-Port-Of: odoo/odoo#238138

Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.

Forward-Port-Of: odoo/enterprise#120107
Forward-Port-Of: odoo/enterprise#119701

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120294
Forward-Port-Of: odoo/enterprise#119084