# How to reproduce
- Create a Product with more than 256 variants
- Publish it to the website
- Go to the website and add a Product Carousel
- Set it to display newest products & hide variants

# The problem
Fewer than 16 products are displayed

# Cause
This issue was already adressed by this commit :
https://github.com/odoo/odoo/pull/195857

But because of limitations for specifically the "Newest Products" filter (cf. original commit message), the fix was only a workaround. Indeed, it increased the search limit to 256 before filtering out the variants, which caused problems when there was more than 256 variants.

But since then, big changes made in 19.0 has allowed us to implement a better fix : https://github.com/odoo/odoo/commit/e3b062e5d3820

# Proposed Solution
Since we can now pass the model in the options :
https://github.com/odoo/odoo/blob/b5069328734e623c12b0de50a177d501f7f0c995/addons/website/models/website_snippet_filter.py#L90

We give "product.template" when the `hide_variants` option is enabled and we filter on products. This allows use to remove the whole workaround that needed increase the limit on product searchs then getting their templates.

A recent commit blocks passing "product.template" since it does not have a dedicated snippet filter : https://github.com/odoo/odoo/pull/257208/changes/8e264ae4ea6ae16bbd410ac384733ff8759938a6

But in the commit message, they mention that this targets snippet in single-record mode, which is not our case. So, we move the logic to only be applied for single-record filters

opw-6054059

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

Forward-Port-Of: odoo/odoo#260340

**Problem:**
In view Inventory valuation, generate entry doesn't work when 
multiple companies are selected. 

In the view only the main company matters. 
That means that even if multiple companies are selected, only the stock 
variation lines related to the main company selected are displayed
(which is expected).
But if you then click on 'generate entry' the account move lines created
will have wrong values (not matching the values appearing in the view)

**Steps to reproduce:**
- create 2 new companies (to have clean accounting)
- create a warehouse for both companies
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From company 1 : 
- create a storable prod with avco perpetual category
- confirm PO for 2  @ 10, receive 
- bill only 1 @ 10

From company 2: 
- make sure the category is also perpetual average from this 
other company
- confirm PO for 2 @ 50, receive, don't bill

Notice how from the 'Inventory Valuation' view, rightfully,
only the main company matters (no matter what 
other comp are selected):
- If main comp is comp 1 there is stock variation lines
for amount of 10 (which is expected because we have 
20 in stock and only 10 in stock valuation account)
- If main comp is comp 2 there is stock variation lines
for amount of 100 (which is expected because we have 
100 in stock and only 0 in stock valuation account)

With comp 1 and 2 selected and comp 1 as main company: 
- click on 'Generate Entry'

**Current behavior:**
- both line have a balance of 110

**Expected behavior:**
- they should have a balance of 10 as we saw 
on the 'inventory valuation' view

**Cause of the issue:**
To generate the data from the 'inventory valuation' 
view, inside _get_report_data() we call stock_value() 
and stock_accounting_value() to compare values 
from inventory and value from accounting. 
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L36-L37

stock_value() sums total_value() of each product in 
the valued accounts
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L90-L94
Whereas stock_acounting_value(), sums the balance 
of each account move line of each valuation account
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L112-L114
All of this is related to the main company because 
we call _get_report_data() with context 'allowed_company_ids' 
set to only the main company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

But when we click on generate entry, 
_get_stock_valuation_account_vals() is called with no context
modification to 'allowed_company_ids' so when we call 
stock_value(),
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L238-L239
total_value will be based on both company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L92

Note that stock_accounting_value() is still rightfully based only 
on main company because we use self.id in the domain
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L105-L108

opw-6168699

Forward-Port-Of: odoo/odoo#263946
Forward-Port-Of: odoo/odoo#262776

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Forward-Port-Of: odoo/enterprise#117357
Forward-Port-Of: odoo/enterprise#117033

### Steps to reproduce:

- Install delivery_envia
- Website > Configuration > eCommerce > Delivery Methods > Envia
- Enable the delivery method, sync the carrier and Publish it
- With a portal user > Shop > Add any product to your cart > Checkout
- Register an address a valid 'Chile' address and confirm say: 
    'street and Number': Avenida Providencia 1432, Depto 402
    'city': Santiago 'zip': 8320000
    'country': Chile  'state': Metropolitana
#### > Envia Error: Invalid Option - String is too long at #->properties:destination

### Cause of the issue:

The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43 when the address is converted here:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542 That being said, the `Chile`'s code states of have been changed in [6694a3942c58ff1a56c9e4b36edbe126dd1e66f8](https://github.com/odoo/odoo/commit/6694a3942c58ff1a56c9e4b36edbe126dd1e66f8) to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6210007

Forward-Port-Of: odoo/enterprise#117280

Steps to reproduce:
===================
1. Go to Event, open an event page
2. Click "Register" & Select a ticket and confirm
3. Switch to edit mode

=> crash.

Cause:
======
The cleanup callback called `hide()` followed immediately by `dispose()`.
Bootstrap's `hide()` is asynchronous — it registers a `transitionend`
callback that fires `_hideModal()` after the CSS transition. `dispose()`
nullifies `this._element` synchronously via `BaseComponent`, so when the
`transitionend` fires and `_hideModal()` tries to access
`this._element.style`, it crashes with:

  TypeError: Cannot read properties of null (reading 'style')

This happened when switching to edit mode while the event registration
modal was open: the `public.interactions` service stopped the interaction,
triggering the cleanup.

Solution:
=========
Listen for `hidden.bs.modal` (fired at the end of `_hideModal`)
and only `dispose()` inside that handler, ensuring `_element` is still
valid throughout the transition.

task-6133395

Forward-Port-Of: odoo/odoo#264365

Issue:
---
Due to this issue, in multi-company environment, wrong fiscal position might be assigned to the order, leading to `incompatible companies` error.

Steps to reproduce:
1- On multi-company setup, assign a website to the second company.
2- Configure pickup method for second company.
3- Configure fiscal positions for both companies.
4- Setup auto invoice for second company.
5- Using public user, add a product to cart and checkout.
6- Use pickup method, and pay.

The order is not confirmed. If you enable debug mode after payment, it will show an `incompatible companies` error.

Cause:
---
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/account/models/partner.py#L247-L279 `_get_fiscal_position` is using environment company to compute the fiscal position.

However, `_compute_fiscal_position_id` causing the issue here is triggered inside `report_saleorder` template with user set as odoobot when trying to to send the confirmation.

As a result, the odoobot company's fiscal position will be used causing this issue.

Fix:
---
We should ensure company from sale order is used by setting it as env company.

opw-6186296

Forward-Port-Of: odoo/odoo#264123

Steps to reproduce
1. Enable "Batch Account Move Lines" in the Payroll settings.
2. Configure two employees' versions with an analytic distribution on the
   same analytic account but with different percentages (e.g. {acc: 50}
   for the first employee and {acc: 70} for the second).
3. Generate a payslip run containing both employees and validate it.

Issue
The generated account move aggregates the two payslips into a single
line whose analytic_distribution matches only the last employee being
processed; the other employee's percentage is silently lost.

`_get_existing_lines` decides whether an incoming line can merge into an
already accumulated one. When the incoming line has an analytic
distribution, the merge condition delegates to
`_check_partially_matching_accounts`:

https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L254-L271
https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L273-L283

That helper returns True as soon as any analytic account of the new
line appears anywhere in the existing line's distribution dict, without
comparing percentages. Two distributions such as {acc: 50} and
{acc: 70} share the same account, so the helper returns True, the
lines are merged, and whichever distribution ends up on the merged line
overwrites the other — the total amount is correct but the analytic
split is wrong.

The logic introduced in commit https://github.com/odoo-dev/enterprise/commit/e40a3166286a6bc546e9543b935233d2a110dc52 successfully addressed merging for rule-level distributions
with composite keys (e.g., {'13,7,12': 40}). However, that implementation is overly inclusive for employee-specific distributions.
It fails to differentiate between cases where the same analytic account is utilized across various employees but with different percentage allocations.
Because it only checks for an account overlap rather than a perfect distributional match, it incorrectly aggregates distinct financial dimensions into a single journal line

Solution
Compare the full analytic_distribution dict by strict equality. Lines
merge only when the distribution is identical (same keys AND same
percentages), keeping the batch feature anonymizing identically
configured employees while preserving one line per distinct
distribution.

opw-6102508

Forward-Port-Of: odoo/enterprise#114156

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#263114
Forward-Port-Of: odoo/odoo#257342

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

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

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264586
Forward-Port-Of: odoo/odoo#241827

# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account

# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears

# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :

```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```

When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.

Why is that field set to NULL ?

Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id

When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.

Take for exemple the following Analytic Line :

```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```

When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :

```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```

So, we need to adapt to search so that it uses the right plan's name.

opw-5897037

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

Forward-Port-Of: odoo/odoo#263652
Forward-Port-Of: odoo/odoo#248236

Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

Forward-Port-Of: odoo/enterprise#116824
Forward-Port-Of: odoo/enterprise#112522

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#117450
Forward-Port-Of: odoo/enterprise#115085

### Issue before this commit:
In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Tax Report and visualize the Annual Tax Report (IT)
3. Go to VF VAT Report
4. See the VF25 is mixing taxes and balances

### Cause of the issue:
The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24).
https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299

It's just a typo in this commit: https://github.com/odoo/odoo/pull/164064/changes/f292ba119d6376dbfb3c1fac4960c9c56a74d938

### Reason to introduce the fix:
From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : 

> Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13.

opw-6172791

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

Forward-Port-Of: odoo/odoo#264379