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:
===================
1. Create a storable product with two variants and untick "Continue selling when out-of-stock".
2. Leave the first variant at 0 in stock, put some stock on the second one.
3. try the "Add to Cart" option of the shop page.

=> The product has no add to cart button, as if it were sold out, while its second variant can be bought. Reordering the variants so that the one in stock comes first brings the button back.

Root cause:
===========
`product.template._is_sold_out()` delegates to `product_variant_id`, which is `product_variant_ids[:1]`, so a whole template is declared sold out on the sole basis of its first variant. `_website_show_quick_add()` then hides the button for the template, whatever the stock of the other variants.

The helper has looked at that single variant since it was written:

- [1] added it to hide the button of sold out products.

Fix:
====
Consider the template sold out only when all of its variants are. The check stops at the first variant in stock, so a product that can be bought still costs a single stock lookup.

[1]: https://github.com/odoo/odoo/commit/4ae197cc770cec2058e1f113209c4f93a4a0f4b2
opw-6520052

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

Forward-Port-Of: odoo/odoo#289022
Forward-Port-Of: odoo/odoo#286781

Steps to reproduce:
===================
1. Publish a combo product whose choices each offer more than one item, so the combo configurator is shown.
2. On the shop, open the product and click "Add to Cart".
3. Select an item for one combo choice only. The dialog's "Add to cart" button stays disabled.
4. Remove the `disabled` attribute from that button with the browser developer tools and click it.

=> The combo is added to the cart with one of its choices unanswered, and the order can be paid in that state.

Root cause:
===========
The incomplete selection is only prevented on the client side, by disabling the button until every choice has been answered. Server side, `/website_sale/combo_configurator/update_cart` only rejects a completely empty selection, never that the selected items cover every choice.

Fix:
====
Reject the request unless the selected combo items cover exactly the combo choices of the product. Comparing the set of choices rather than counting the items also rejects a selection answering the same choice twice while leaving another one unanswered.

opw-6478837

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

Forward-Port-Of: odoo/odoo#289005
Forward-Port-Of: odoo/odoo#283465

**Issue**
When a move has several move lines, the printed quantities are not rounded, causing floating-point arithmetic artifacts to appear on the report.

**Steps to reproduce**
- Create and confirm a PO for 15.6 units of a product.
- On the receipt, change the quantity to 17.8 (this splits it into two stock move lines).
- Validate the receipt and print the delivery slip. -> The ordered quantity on the generated PDF is not rounded (floating-point arithmetic issue).

**Cause**
While printing the delivery slip, quantities are aggregated by product: https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/report/report_deliveryslip.xml#L174

No rounding is performed while subtracting quantities from the ordered quantity (resulting in 13.399..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L927

Nor while adding the second move line's quantity back to the ordered quantity (resulting in 15.599..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L938

**Additional note**
Same issues arise for `packaging_qty_ordered`, `quantity` and `packaging_quantity`.

opw-6469422

Forward-Port-Of: odoo/odoo#286846
Forward-Port-Of: odoo/odoo#283792

# How to reproduce
- Start a new db with the design-themes addons
- Install the eCommerce module
- Skip the first website configurator
- Go to Website > Configuration > Settings > New website
- Go through all the steps as usual

# The issue
At the last step, you will get, depending on the version either :
- A traceback, pointing out the fact that a template is missing
- A popup signaling that another module operation is being processed,
even though there are none

The configurator won't go through in both cases

# Cause
When calling `configurator_apply`, we will try to get the content of
every snippet specific to theme installed with the website :
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/website.py#L910

But, when trying to find the
'website_sale.configurator_homepage_s_dynamic_snippet_category_list'
view, we find nothing and an error is thrown.

This view should be created by the `_generate_primary_snippet_templates`
function, which is called when loading any theme module or `website`
or `website_sale`:
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/ir_module_module.py#L594

The issue is that, to know which snippets to install, that function
relies on `get_current_website()`:
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/ir_module_module.py#L694

Which relies on multiple things to find the current website, notably
the current request's session :
https://github.com/odoo/odoo/blob/ef6765208d400aa1252cd4dff5bc074ea551bbc2/addons/website/models/website.py#L1374-L1381

Since [this commit], the request is not kept when creating a new
registry, which is done when loading a module.

`get_current_website()` fallbacks on the first website's theme, which
is the default theme (since we skipped the first configurator). That
theme does not have the `website_sale` snippet in its manifest, contrary
to others.

# Proposed solution
Since a new registry is created, we cannot use the context, nor the
current request. We also cannot add a parameter to the
`_generate_primary_snippet_templates` function since we are in stable
(It would not help much anyway because this function is called when
loading a module, so giving the current website is not possible).

This means that we have to stop relying on `get_current_website()` to
differentiate between the two use case :
- Installing a theme module
- Installing a module with specific snippets

We can determine if the module being installed is a theme by looking at
its category. If it is not, we assume its the other use case as there
should not be any other.

In that case, instead of installing the snippets of the theme of the
current website, we check the theme of all websites.

Later in the code, we take only distincts snippets and check that a
corresponding view do not already exist, so there should be no risk of
duplicate :
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L692
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L712
https://github.com/odoo/odoo/blob/1f2ea7be8377c906ded75da893d739109db93c4d/addons/website/models/ir_module_module.py#L608

Furthermore, I believe it makes more sense to check every website
anyway. If the `website_sale` module is installed, and there already
exists multiple website with different themes, these themes might
require different `website_sale` specific snippets.

opw-6517556

[this commit]: https://github.com/odoo/odoo/commit/be8c85b4ccb10d6f16ddea3ab493e4c9aac749e1

Forward-Port-Of: odoo/odoo#285935

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

### Steps to Reproduce:
1. Go to Sales > Products and select a product
2. Upload an image for the product
3. Go to Settings > Technical > Attachments
4. Click on one of the image attachments
5. Observe the Client Error: "Uncaught Promise > Invalid props for
component 'Many2One': 'domain' is not a function"

### Issue:
In `attachment_patch.js`, the domain for the `Many2OneReferenceField` is overridden when an attachment is linked to another attachment. The patch calculates the domain and incorrectly assigns a static Array (using `.toList()`) to `props.domain`. In Odoo 19, the `Many2One` component enforces strict prop validation (caught when Owl's debug mode is enabled during testing), causing a crash because it expects the domain prop to be a function.

### Solution:
We can just wrap the resulting domain Array in an arrow function so that it evaluates dynamically when the `Many2One` component mounts. Also added a unit test to explicitly cover this patched scenario. The test manually applies a local patch to `Many2OneReferenceField.prototype` to accurately replicate the environment and verify the fix.

### For saas-19.4+:
### Issue:
In the MockServer, when a `many2one_reference` field points to its own model (for example, an `ir.attachment` linked to another `ir.attachment`), the record is incorrectly erased and replaced by only its ID. This causes testing environments to lose record data when evaluating self-referencing relations, preventing accurate unit testing.

### Solution:
We can update the mock model mapping to properly retain the full record data when the comodel is the same as the main model.

opw-6563954

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

Forward-Port-Of: odoo/odoo#287951

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

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

Hide Open Document on working files when no attachment

Problem: In working files checks with attachment, Open Document button and trash icon are visible even if there is no attachment uploaded yet.

Cause: We check for existence of attachment by `t-if="record.attachment_ids"`, but `record.attachment_ids`, `record.attachment_ids.value` and `record.attachment_ids.raw_value` are all truthy even if there is no attachment uploaded yet.

Fix: Use `invisible="not attachment_ids"` just like before.
***
Fix formatting when clicked outside without any change

Steps to reproduce:-
- Create a budget with a P&L report.
- Set a value in a cell.
- Then press the edit amount, click somewhere else without changing the amount.
- The amount is no longer formatted properly.

Cause: When user clicks edit, we populate formatted value for locale format type
but when user clicks outside without change, in function `onBlur` we compare
populated amount(which is formatted) with cell's no format value. So it
mismatches and `focused` is never set `false`.

Fix: Make getter `editableValue`, which returns `editableNumericValue` for
locale format type and no format value otherwise. Now use this `editableValue`
in `onFocus`, `onBlur`(this solves the bug) and `inputValue` to make it more
clear.

***
[task-6413368](https://www.odoo.com/odoo/project/967/tasks/6413368)

Forward-Port-Of: odoo/enterprise#131989

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#132715
Forward-Port-Of: odoo/enterprise#131085

Steps to reproduce
------------------
1. Open a PoS that has a preparation display.
2. Create an order and go to the payment screen without sending it to the kitchen.
3. Enable Invoice, set a customer and validate the payment.

-> The order does not appear on the preparation display. Without the invoice it does appear.

Why it's happening
------------------
`sync_from_ui` in `pos_enterprise` only creates the preparation lines when the order state is 'paid'. Validating an invoiced order pays it and creates the invoice in the same call, and `_generate_pos_order_invoice` sets the state to 'done', so when the state is checked it is not 'paid' anymore and the order is skipped.

Until 19.3, these skipped orders were still sent by the sync coming with the `preparation` context, which was creating the lines without looking at the state. In 19.4, 8491f7a74363 changed this sync to only ask the displays to reload their orders, so the lines of the skipped orders are not created anymore. On master, invoicing does not set the state to 'done' since f1f5a0b8f8a3, so the order stays 'paid' and its lines are created.

The fix
-------
Also create the preparation lines when an order sent as 'paid' by the client ends up 'done', meaning it was paid and invoiced by the current call.

opw-6513655

Steps to reproduce:
- Ecuadorian company, PoS with a preparation printer (or use the "Back" button on the feedback screen)
- Open a session, add a product, go to the payment screen
- Select a customer, uncheck "Invoice", pay in cash and validate

Issue:
An invoice is created and sent to the SRI although "Invoice" was unchecked.

Cause:
l10n_ec_edi_pos patches PosOrder.setup() to force to_invoice = true. setup() runs not only on creation but every time the record is reloaded from the server, so the sync done at validation flips the flag back to true in the browser. Since the paid order can now be re-synced after validation (kitchen printer, "Back" on the feedback screen), the server processes it in process_saved_payments, writes to_invoice = True and generates the invoice.

Fix:
Only apply the Ecuadorian default when the loaded values carry no to_invoice, i.e. for a newly created order. Reloaded records keep the value the user chose.

opw-6572987

Forward-Port-Of: odoo/enterprise#131612

Currently, an error occurs when opening the Rental Order Lines Schedule view.

**Steps to Reproduce:**

 - Install the `sale_stock_renting` module.
 - Go to `Settings` and enable `Variants`.
 - Go to `Rental` > `Products` and create a product.
 - In the `Attributes & Variants` tab, add an attribute with two values and save.
 - Delete all variants using the `Variants` smart button or from `Inventory` > `Products` > `Product Variants`.
- Return to the `Product` and click the `In Renting smart button`.

`IndexError: list index out of range`

When a product template is created, a product variant is automatically generated if the 
product has no attributes. Deleting this variant also deletes the product template [1].
By explicitly creating attribute values, a dynamic product variant is generated. Deleting 
this variant does not delete the product template because of the dynamic attribute [2]. 
When the In Renting button is clicked, it it going to open the rental order lines Schedule 
view and adds default_product_id to the action context. Since no product variants exist 
anymore, accessing the default product variant raises an error [3].

This commit ensures that default_product_id is not added to the context when the product 
template has no product variants

[1]: https://github.com/odoo/odoo/blob/1f70b81eeebcc62b64c18772915e2f4696e189e7/addons/product/models/product_product.py#L486

[2]: https://github.com/odoo/odoo/blob/1f70b81eeebcc62b64c18772915e2f4696e189e7/addons/product/models/product_product.py#L478-L480

[3]- https://github.com/odoo/enterprise/blob/98ec35f3f17a2b706ad4fcc4d6161d12d05eadfd/sale_renting/models/product_product.py#L69

[4]: https://github.com/odoo/odoo/blob/942d3892c33e7ccdcfec260c3da37095069b699e/addons/stock/models/product.py#L635-L643

[5]: https://github.com/odoo/odoo/blob/942d3892c33e7ccdcfec260c3da37095069b699e/addons/stock/models/product.py#L601-L612

sentry-7637715724

Forward-Port-Of: odoo/enterprise#132401
Forward-Port-Of: odoo/enterprise#126356

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

[FIX] account_reports: don't rely on self.env.company in _is_available_for

This caused issues in snapshot generations, where the function is called without forcing the active company in the context. Relying on companies[0] should do the same in other contexts it is called in, and is more resilient.

===============================================

[FIX] account_reports: snapshots: properly sandbox move lines per company when deducing the first date for snapshots

===============================================

[FIX] account_reports: snapshots properly access subranches when checking snapshots to delete

_accessible_branches only returns the companies that are in self.env.companies. If we want all the sub-branches (and the company itself), we should search with a child_of. This was found while debugging a test, because the accessible branches returned for a company where an empty recordset instead of the company itself, just because it wasn't in self.env.companies.


===============================================

[FIX] account_reports: snapshots: don't delete snapshots uselessly when there is a temporary lock date exception

Before this commit, when checking which snapshot needed to be deleted, we always removed the ones created after a temporary lock date exception, without considering the end time of this exception. Also, we were only deleting the snapshots with a higher or equal create_date, which was wrong: snapshot created before the exception should also be deleted.

Forward-Port-Of: odoo/enterprise#132557