Steps to reproduce:
- Open a PoS session so the browser caches the data (IndexedDB)
- Add an attribute line on a product available in PoS, using an attribute that already existed and was not modified since
- Reopen the PoS and click the product

Issue:
TypeError: undefined is not an object (evaluating 'values[0].is_custom') in openConfigurator. The attribute line is loaded but none of its values are; the variants have no attribute values on the frontend. Closing the session or reloading the browser does not help since the cache is kept.

Cause:
On an incremental load (pos_last_server_date in context), every model only returns the records written after the last sync. The domain of product.template.attribute.value restricts attribute_id to the ids in data['product.attribute'], which in that case only holds the attributes modified since the last sync. Values created on an older attribute are therefore excluded, and the frontend drops the ids it cannot resolve.

Fix:
Filter attribute_id with the domain of product.attribute itself instead of the ids of the records returned in the current load. A full load returns the same records as before.

opw-6568808

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

Forward-Port-Of: odoo/odoo#288065

Steps to reproduce:
- Import a product CSV with one row per attribute value ("Product Values" column) and an image URL on every row, or create several variants of the same template in one `create()` call with an image.
- Open the product: neither the template nor the variants have an image. Products without attribute values imported in the same file are fine.

The import creates all variants of a template in a single batch. The inverse of `image_1920` is applied record by record: the first variant finds no image on the template and writes its image there. Writing `image_1920` on the template invalidates the image cache of every product.product, including the sibling variants being created, whose `image_1920` is protected during the inverse and therefore reads back as empty. The next variant then takes the "clear the image from the template" branch and writes `False` on the template, undoing the first write. Nothing is stored.

Read the value to inverse for every record before writing anything, so the invalidation triggered by the template write cannot change what the following records write.

opw-6545651

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

Forward-Port-Of: odoo/odoo#287419

Issue:
----------------------------------------
The domain of the field `hr_responsible_id` isn't computed. Also it should contain `hr_holidays.group_hr_holidays_user`.

Cause:
----------------------------------------
The domain of the field is returned by `_get_hr_responsible_domain()` as a string which is not supported.

https://github.com/odoo/odoo/blob/2ea452d03aa0cbfe360c539fb3b29a7b89aa7297/odoo/orm/fields_relational.py#L112-L123

`validated()` returns `None` so the domain is left empty.

Solution:
----------------------------------------
Return a list instead of a string.

Also, override the field in `hr_holidays` and and the condition on `hr_holidays.group_hr_holidays_user`.

Note:
----------------------------------------
This [commit](https://github.com/odoo/odoo/commit/ff50687bad2939db882e75ae20f28e6155fa2191) did the same thing in saas-19.4 but added a useless field in `hr.employee` because it did not catch the error of the string being wrong.

opw-6545508

Steps to reproduce:
- Open a PoS so that the Opening Control popup is displayed.
- Cut the connection to the server without the browser going "offline" (e.g. the router stays up but the internet link is down).
- Click on "Open Register".
- Restore the connection, make some orders, close the session.

Issue:
The session is closed with orders but was never opened on the server: it has no opening date, keeps its temporary name "<config>/00000", and the opening cash was never recorded.

`set_opening_control` was called with the `queue` flag. On a ConnectionLostError the call was silently pushed to the in-memory unsync queue, and the popup marked the session as opened locally and closed itself. That queue is only replayed on the browser `online` event, which is never fired when the device stayed connected to its local network, and it is lost when the tab is closed or reloaded. Meanwhile the server accepts orders on a session in `opening_control`, and nothing checks it at closing.

Opening the register is not an operation that can be deferred: the session must be opened before any order is made. The call is no longer queued. When the connection is lost, the user is told that the register cannot be opened offline, and the popup stays open so the opening can be retried once the connection is back.

opw-6580262

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

Forward-Port-Of: odoo/odoo#289036
Forward-Port-Of: odoo/odoo#288899

Problem: When a time off type is configured to require a supporting document, the system should prevent users from submitting a request without one.

However, users could bypass this requirement by creating and saving a request without uploading a file. Because the validation was not strictly enforced during creation or subsequent write operations, requests could enter or remain in active states without the mandatory documentation.

Solution: This commit ensures the system enforces mandatory attachments during the modification of time off requests that require a supporting document. The system now evaluates state transitions to block undocumented submissions.

Steps to reproduce(runbot v19):
1. Go to Time Off > Configuration > Time Off Types, create a new leave type and enable the "Allow To Attach Supporting Document" setting.
2. Create a new time off request for this type, leave the attachment empty, and save.
3. Notice that the system allows the invalid request to be saved and persist in the database without a document.

opw-6413621

Forward-Port-Of: odoo/odoo#278991

**Issue**
Cost of SO might be wrong with MTO+Manufacture product

**Steps to reproduce**
- Activate margin in settings
- Create 2 products: 
  - product A: MTO + Manufacture, 1 qty onHand, standard price to 10 with avco valuation 
  - product B with a standard price of 5
- Create a BOM with the product B as comp
- create and confirm a SO for 1 unit of product A
- Go to the associated MO and produce all
- confirm the delivery linked to the SO -> The cost on the SO is 6.25, while the standard price remains 7.5

**Cause**
While confirming the MO, it linked the producing move (which has a unit value of 5), to the SO: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_mrp/models/mrp_production.py#L41-L48

While confirming the delivery, it triggers `_compute_purchase_price` since the picking state changes: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_stock_margin/models/sale_order_line.py#L10-L11 which will eventually takes all the moves links to the sale order to compute the price: https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/sale_stock_margin/models/sale_order_line.py#L21 https://github.com/odoo/odoo/blob/a6f22922a97399265c04855b5d9b18ac7ac609a0/addons/stock_account/models/stock_move.py#L701-L714

Which gives an averaging between 5 and 7.5 -> 6.25. Indeed, the unit value of the out move is the standard price: https://github.com/odoo/odoo/blob/8387c28423e8208e53939da3ef5a074c072d33a6/addons/stock_account/models/stock_move.py#L353

opw-6418948

Forward-Port-Of: odoo/odoo#283940
Forward-Port-Of: odoo/odoo#280712

In `account.asset-sk.csv` the asset-account column has slipped by one row for the last two entries, so each of those two models pairs an asset account with the accumulated depreciation account of a different asset class.

As shipped (Slovak account names glossed in English):

    sk_asset_basic_herd_and_draft_animals
        asset         029000  Ostatný dlhodobý hmotný majetok   "Other tangible fixed assets"
        depreciation  086000  Oprávky k základnému stádu        "Accumulated depreciation, basic herd"

    sk_asset_other_tangible_fixes_assets
        asset         031000  Pozemky                           "LAND"
        depreciation  089000  Oprávky k ostatnému DHM           "Accumulated depreciation, other tangible"

Every other row in the file pairs an account with the accumulated depreciation account that names it: 012000 with 072000, 021000 Stavby ("Buildings") with 081000 Oprávky k stavbám ("Accumulated depreciation, buildings"), and so on. Only these two break the pattern, and both break it the same way.

`account.account-sk.csv`, in the same directory, disagrees with them and is right: it links 026000 Základné stádo a ťažné zvieratá ("Basic herd and draft animals") to the herd model and 029000 to the other-tangible one, and gives 031000 Pozemky no asset model at all, land not being depreciable under Slovak law or any other.

The consequence is not cosmetic.
`account.account.asset_model_ids` creates an asset when a vendor bill line hits the account, and the asset takes its accounts from the model. So on a Slovak database a bill booked to 029000 "Other tangible fixed assets" produces an asset whose value sits on 031000 "Land" and depreciates over six years, while the account that should have carried it never does.

Corrected to the accounts that both the accumulated depreciation side and `account.account-sk.csv` point at:

    sk_asset_basic_herd_and_draft_animals   asset 026000  Základné stádo a ťažné zvieratá  "Basic herd and draft animals"
    sk_asset_other_tangible_fixes_assets    asset 029000  Ostatný dlhodobý hmotný majetok  "Other tangible fixed assets"

Verified by loading the SK chart on a clean database: all ten asset models now pair with their own accumulated depreciation account, and none points at 031000.

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

Forward-Port-Of: odoo/odoo#289542

Problem:
When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: "   "`), the link popover displays an empty clickable preview area.

Cause:
`LinkPopover` assigned raw metadata values directly. Non-empty whitespace strings evaluate to truthy values in JavaScript (`"   "` is truthy), preventing fallback to the default URL or empty string.

Solution:
Trim the metadata values (`og_title`, `og_description`, `og_image`) when populating state so that whitespace-only values evaluate to empty strings and trigger appropriate fallbacks.

Steps to reproduce:
- Open HTML editor.
- Add a link with URL `https://netorg4182089.sharepoint.com/:v:/s/projects/IQD72ajP3WOBT4jcAu_1qLfIAamL9lvrq4ls1Bs9XCyXJvw?e=vQ9wH3`.
- Open the link popover. => Observe that the popover title falls back to the URL instead of showing an empty clickable space.

opw-6564118

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

Forward-Port-Of: odoo/odoo#288188

Currently, an error occurs when a user opens the website and Live Chat is initialized with an invalid URL regex.

Steps to Reproduce:
 - Install `website_livechat` without demo data.
 - Open `Live Chat` and, in the `YourWebsite.com` channel, click the 
   `three-dot` menu and select `Configure Channel`.
 - Go to the `Rules` tab.
 - Add a rule, select `Welcome Bot` in `Chatbot`, and set an invalid regex such as 
   `*` in `URL Regex` and save.
- Click `Join Channel`.
- Open the `website`.

`re.PatternError: nothing to repeat at position 0
when serializing dict item 'result'
`
 - when `URL Regex is '['`

`re.error: unterminated character set at position 0 when serializing dict item 'result'`

When a user opens the website, Live Chat is initialized by checking operator availability and 
finding the matching country/URL rule [1]. The rule matching checks whether `regex_url` matches 
the current page URL. It uses `re.search()` [2], which compiles the regex pattern before searching. 
If `regex_url` contains an invalid pattern such as `*`, `re.search()` raises `nothing to repeat at position 0` 
because `*` must follow a preceding regex element. Similarly, `[` starts a character set (`[...]`) 
but has no closing `]`, causing `unterminated character set at position 0`.

This commit adds a constraint to validate `regex_url` and reject invalid regex patterns 
when creating or updating Live Chat rules.

[1]- https://github.com/odoo/odoo/blob/f962f1eccecfdbc95375f795174c8f687459b521/addons/im_livechat/controllers/main.py#L87

[2]- https://github.com/odoo/odoo/blob/f962f1eccecfdbc95375f795174c8f687459b521/addons/im_livechat/models/im_livechat_channel.py#L387

sentry-7679767396


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

Forward-Port-Of: odoo/odoo#283545

eproduction steps:
 - MRP subcontracting + purchase
 - Subcontracted product with BOM
 - Create PO with a qty > 1 for this product
 - Go into barcode
 - Scan > 0 and < all of the expected quantity
 - Back out of barcode
 - Click validate -> Error **OR** Go back into barcode, attempt to validate -> Error

Added the StockMove and StockPicking classes to stock_barcode_mrp_subcontracting
to extend functions `_subcontracted_produce`, `_clean_merged`, and `split_uncompleted_moves`
to use a new context flag, `keep_subcontract_production`. When this flag
is set, the move Barcode creates from the split keeps the MO of the move
it was split from rather than splitting the MO in two, gives that link up
before it is merged away so its cancellation does not cancel the MO, and
the MO quantity is resynced with the merged move afterwards.

Error thrown here:
https://github.com/odoo/odoo/blob/f84eeb3ed1421e0cc07c906ff6444734dc01d35f/addons/mrp_subcontracting/models/stock_move.py#L248

opw-6428928

Forward-Port-Of: odoo/enterprise#131459

Tour `hr_contract_salary_tour` fails non-deterministically on step `trigger: 'span[name="Gross"][value="2886.87"]',`

There are multiple steps in the tour where a value is input and then a click is made targetting `label:contains(Transportation)`[^1]. The click is made to force the update of the salary configurator's values. However, the selector is not precise enough, multiple elements match, some of which clickable and with an influence on the configurator.

By looking at the screenshots from faulty runbot builds, we can see a value specified for the "Train Transportation" option, although it is not supposed to be selected at this point of the tour, which causes the value of the gross to be
wrong.

Runbot screenshot:
<img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/a520cacf-f900-4aad-ae6b-d9b7b68da716" />

Selector results (random runbot):
<img width="1918" height="613" alt="image" src="https://github.com/user-attachments/assets/caae96d4-5026-48cc-aad7-d1283ab5549a" />

-----
runbot-242057

[^1]: eg. https://github.com/odoo/enterprise/blob/7ff50cf2abc02cb71f3b50d85a92f4ee52e1a66c/test_l10n_be_hr_payroll_account/static/tests/tours/hr_contract_salary_tour.js#L429

Forward-Port-Of: odoo/enterprise#132384

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the CO Company.
- Disable `Test environment` and enable `DIAN Demo Mode` in the invoicing settings.
- Set a `Technical control key` on the `Customer Invoices` journal.
- Create and confirm an invoice with Terms and Conditions.
- Send the invoice to `DIAN`.
- Open the generated XML file and observe the `cbc:Note` tag.

**Observation:**
The `Note` tag contains the `technical control key`.

**Expected behavior:**
The `Note` tag should only contain the Terms and Conditions value
from the invoice. (Confirm with PO [1])

**Root Cause:**
At [2] and [3], the code includes the `technical key` in the `Note` tag.

[1]:
https://www.odoo.com/mail/message/1164671931

[2]:
https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L664

[3]:
https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1600-L1603

opw-6513843

Forward-Port-Of: odoo/enterprise#132606
Forward-Port-Of: odoo/enterprise#131495

Issue:
Currency rate for payment is recomputed up to 6 digit. However, it may differ from the official one stored in db up to 4 digits. Which creates differencies between invoice and payment rate made at the same date.

Steps to reproduce:
- In MX company,
- Enable USD,
- Set currency rate for today to 1 USD = 17.4455 MXN
- Create a PPD invoice (due date > 40 days) in USD
- Add a line with
	- qty: 1,
	- unit_price: 3.488
	- tax: 16% (default tax)
- Send it to CFDI
- Create payment
- On the invoice Form click on "Update Payment"

Current behavior:
- In the CFDI sheet, Payment and Invoice XML files will have different currency rates

Expected behavior:
- In the CFDI sheet, Payment and Invoice XML files will have the same currency rate

Cause:
PACs require having the payment `amount` to be equal to `currency_amount * currency_rate`. For huge amout it may happen that using the 6 digits rounding of currency rate to compute the amount won't fall exactly on the two digit precision for the amount and payment would be refused. Therefore, for all payment, we recompute a 6 digits precision `currency_rate` from `amount` and `currency_amount` then using it to compute the final amount. However, Banxico (Mexican central Bank) publish rates with a 4 digit precision. Recomputing the currency rate up to 6 digits may slightly change it from the 4 digit precision official currency rate.

opw-6411530

Forward-Port-Of: odoo/enterprise#131130
Forward-Port-Of: odoo/enterprise#129700

### Issue before this commit:
When issuing a Delivery Guide for an "Itinerant issuer transfer CP", SUNAT rejects the document with error 3416 because the establishment code of the arrival point is being reported.

### Steps to reproduce the issue:
1. Download Stock, l10n_pe_edi_stock and l10n_pe_reports_stock
2. Create one contact setting a valid RUC
3. Go to settings and insert Credentials for Sunat Delivery Guide API
4. Create a new warehouse
5. Go to deliveries and create a new one with:
	1. Delivery Address: the contact you created
	2. Transport Type: Public Transport
	3. Reason for transfer: Itinerant issuer transfer CP
	4. Operator (in the PE EDI tab): any
6. Validate the delivery
7. Generate the delivery guide
8. There was an error communicating with the SUNAT service. Details: 400 Client Error: Bad Request for url: https://api-seguridad.sunat.gob.pe/v1/clientessol/test/oauth2/token/
9. If you download the generated XML, you will see that the node <cbc:AddressTypeCode> inside <cac:DeliveryAddress> is being generated with a default value of "0" but it should not be there

### Cause of the issue:
The UBL template automatically forces the <cbc:AddressTypeCode> node with a default value of "0" for any delivery address associated with a RUC (identification type 6). However, SUNAT's validation rules strictly forbid this node when the transfer reason is 18.

### Reason to introduce the fix:
Update the XML template to conditionally omit the <cbc:AddressTypeCode> tag inside <cac:DeliveryAddress> whenever the l10n_pe_edi_reason_for_transfer is '18'. This ensures compliance with SUNAT's validation rules and allows the successful generation of the delivery guide.

opw-6493067

Forward-Port-Of: odoo/enterprise#131431

Circular 99/2025/TT-BTC (effective FY2026) replaces Circular
200/2014/TT-BTC. The Profit & Loss statement (Mẫu B02-DN) gains a
new mandatory line, "Lãi/lỗ của hoạt động bán, thanh lý bất động sản
đầu tư" (mã số 21), computed from the new 5117/6327 sub-accounts
(see the paired l10n_vn commit). Financial income, financial
expenses and the interest memo line shift to mã số 22/23/24
accordingly, the "Net profit from operating activities" formula is
updated to include the new line, and all following line
numbers/labels are renumbered to match the printed form. The
interest memo line itself is renamed from "Chi phí lãi vay" to
"Chi phí đi vay" (Borrowing costs), per the gazette text.

Also, per revised guidance:
- Revenue and cost of goods sold now exclude the new investment
  property sub-accounts (5117/6327), so those amounts aren't
  double-counted between the main lines and the new gain/loss line.
- Other income is now computed from the "income_other" account type
  instead of a hardcoded account code, matching how the chart of
  accounts already classifies it.

Both the Balance Sheet and Profit and Loss VN reports also declare
an extra "Code" string column (for the printed-form mã số) alongside
"Balance". Core's growth-comparison heuristic only turns on the auto
growth-% column when there are exactly 2 total columns; with
Code+Balance that becomes 4 once a comparison period is added, so
the % never renders even though the underlying side-by-side
comparison values are fine. account.report exposes
filter_growth_comparison as a toggle independent from
filter_period_comparison for exactly this case (see Trial Balance
and the Deferred reports), so both reports set it to False: period
comparison stays available, only the auto growth-% column is
suppressed.

Task-6518304

Forward-Port-Of: odoo/enterprise#131085