**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:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Forward-Port-Of: odoo/odoo#264710
Forward-Port-Of: odoo/odoo#259566

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

The `show looking for help duration in the sidebar` test has been flaky since [1].

The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`.

 This creates several race conditions:
- Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data.
- Channel state fetched after the user joins via `/mail/data`.

The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed.

This commit splits the test to preserve coverage while avoiding the problematic rapid state transition.

runbot-242278

[1]: https://github.com/odoo/odoo/pull/252738

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

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

__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#117247
Forward-Port-Of: odoo/enterprise#114147

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#116961
Forward-Port-Of: odoo/enterprise#112578

1. The `MPESA` payment method needs a callback url where it does a
   `POST` request with the transaction details. Since the call comes
   from safaricom, CSRF will block those requests. This commit will
   disable CSRF checks on the callback endpoints which are expected to
   be called from an external service
2. Sometimes the `web.base.url` parameter is automatically set to http.
   But safaricom expects https for all the urls. So we need to ensure
   that the urls we send on `lipa_na_mpesa_register_urls` use https,
   otherwise the registration fails with an `invalid url` error.
   Additionally, I added the error message in case of error
4. In addition to the business short code we also need a till number for
   transactions. Since this is stable, I've added the till number as an
   extension of the business shortcode field and then parse it before
   usage. On master there is a new PR which will properly separate the
   fields

Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833)

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

Forward-Port-Of: odoo/odoo#254993

Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377).

In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`).

When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass.

In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors.

To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present.

runbot-error-id~242235

Forward-Port-Of: odoo/enterprise#117075
Forward-Port-Of: odoo/enterprise#112486

__
## Short functional explanation of the error
When we set the departure of an employee. The version is retrieved using the dismissal date. However, employees can work after their dismissal date, until their departure (in the case of a notice, for example). Therefore, the departure date should be chosen instead.

## Reproduction Steps
1. Go to Employees and create a new employee. In the Payroll tab, set a start date for their contract. Hit save.
2. This will create a version. You can see it top right, with the contract date. Click on the '+' next to it and set a date later.
3. Click on the cog in the top left and click End of Collaboration. Set an End Reason. Set the Dismissal Date to occur during the first version and the Departure Date to occur during the second version. Then, click Schedule.

### Expected behavior
The Departure tab should appear when clicking on the second version, top right.

### Unexpected behavior
The departure tab appears on the first version.

## Origin of the issue
To select the version on which the departure occurs, we use this line of code:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/hr/models/hr_employee_departure.py#L117 `departure_date` should be used instead.

__
opw-6079675

Forward-Port-Of: odoo/odoo#264667

* = hr_holidays

Before this commit, when displaying the IM status icon for employees on leave of companies the user does not have access to, we would not display the `fa-plane` icon or the "Back on" indicator.

Steps to reproduce:
- Create a new company X
- Create a new employee Y (with user) in company X
- With a user who does not have access to company X open the General channel member list -> no leave icon, open the avatar card -> no icon

This happens because since [1] the leave IM status icon is computed client side using the employee information, rather than computed on the `im_status` field itself.
This however causes problem in a multi-company context due to the field `employee_ids@ResUsers` having a field-level domain restricting to the requesting user's active companies.

This commit fixes the issue by fetching all of the user's employee_ids regardless of active company.

[1] https://github.com/odoo/odoo/pull/210189

task-6191367

Forward-Port-Of: odoo/odoo#263024

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Forward-Port-Of: odoo/odoo#262635
Forward-Port-Of: odoo/odoo#260138

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

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount.

This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`.

This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time.

[1]: odoo#169264
[2]: odoo#154349

Forward-Port-Of: odoo/odoo#263860

**Description of the issue this PR addresses:**
Previously, when a livechat conversation ended, it was never automatically 
marked as read. The existing `mark_as_read` mechanism depends on the 
composer being focused, but ended livechat conversations hides the composer, 
and the chat window does not focus the thread automatically 
(focus only happens on explicit click).

This made it impossible for the read state to be triggered through the normal 
path, leaving agents with persistent unread indicators on closed livechat 
conversations.

**Desired behavior after PR is merged:**
- Focus the composer when present.
- Focus the conversation otherwise.

This ensures the read state is correctly triggered when the conversation
is effectively in focus.

task-[5900038](https://www.odoo.com/odoo/project/1519/tasks/5900038)

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

Forward-Port-Of: odoo/odoo#263607
Forward-Port-Of: odoo/odoo#253609

Pre-requisite:
---------------------------------------
1. Install the Time Off module
2. Create a new company (e.g, Test Company)
3. Create New Timeoff Type: 
    * Ensure a default company is set (e.g, YourCompany)
4. Duplicate the created Time off type: 
    * Remove (Copy) from the name so both records share the same name
    * Clear the Company field on the duplicated record

Steps to reproduce:
---------------------------------------
1. Go to Time Off type which has no Company
2. Allocation Smart button > New
3. Set allocation for some days (e. g, 10 Days) > Approve allocation
4. Now, click on Employee > Time Off smart button
5.  On the Dashboard, you can see allocated leaves
6. Click on any day to create a Time Off Request

Observation:
---------------------------------------
The allocated Time Off Type is not available in the request wizard, even though allocation exists.

Issue:
---------------------------------------
When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`).
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294

If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously!

Solution:
---------------------------------------
Directly match records using their unique ID.
This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name.

opw-6105759

Forward-Port-Of: odoo/odoo#264104
Forward-Port-Of: odoo/odoo#261680

# 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

The `show looking for help duration in the sidebar` test has been flaky since [1].

The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`.

 This creates several race conditions:
- Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data.
- Channel state fetched after the user joins via `/mail/data`.

The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed.

This commit splits the test to preserve coverage while avoiding the problematic rapid state transition.

runbot-242278

[1]: https://github.com/odoo/odoo/pull/252738

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

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

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#114212
Forward-Port-Of: odoo/enterprise#98571

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

Steps to reproduce:
===================
1. Configure website with at least 1 language installed different from English. ex: English and French.
2. As anonymous user, change wehbsite language and make a donation via the donation snippet.
3. Check the outgoing confirmation email.

=> Email body is rendered in English.

Cause:
======
The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in.

Solution:
=========
`payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation.
- override it in the `/donation/transaction` controller with `request.env.lang`
when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context);
- render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`.

opw-5875338


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

Forward-Port-Of: odoo/odoo#259351

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

*:website, website_payment

> Commit 1:

[FIX] web_editor: prevent infinite bounce loop when clicking undo
Steps to reproduce:
1. Click on a snippet without dragging it.
2. Notice that the "Drag building blocks here" section starts bouncing.
3. Observe that a step is added to the history (Undo becomes available).
4. Click on Undo button.

Issue:
1. The `o_catch_attention class` is repeatedly added and removed, creating unnecessary history steps in the editor.
2. No actual changes occur in the wrap area, yet the editor records history steps.
3. This leads to an infinite bounce loop when using Undo/Redo.

Expected behavior:
1. The Undo button should not be activated.
2. Infinite bouncing should not occur.

This PR prevents unnecessary history steps by disabling history tracking during this phase using `observerUnactive` and `observerActive`. This ensures that the editor does not record redundant changes, preventing infinite bounce loops.
 
 
 > Commit 2:
 
 [FIX] website_payment: fix donation amount not updating issue
 Steps to Reproduce:
1. Go to Website → Add a Donation snippet.
2. Enter a custom amount and click "Donate". You will be redirected to the donation/pay page.
3. Use the browser's back button to return to the previous page.
4. Change the amount in the custom amount field.
5. Click "Donate" again.
- The old amount is still used instead of the new one.

Expected Behavior:
The donation amount should update correctly when changed.

The issue occurs because clicking the "Donate Now" button appends a hidden value to the form snippet, which is then used in payment_form. When navigating back and selecting "Donate Now" again, a duplicate hidden value is added instead of replacing the previous one. This PR ensures that if a value already exists, it is replaced instead of being
appended, resolving the issue.


> Commit 3:

[FIX] web_editor: fix dropdown options value

Steps to reproduce:
1. Go to the website and drag and drop the form snippet.
2. Change the action to 'Subscribe to Newsletter'.
3. Click on multi-checkbox field to view its options.

- Even after selecting an option, it remains in the dropdown, allowing multiple selections of the same option.

Expected behaviour:
- Once an option is selected, it should be removed from the dropdown.

Solution:
This PR removes the count from the display name, ensuring correct form behavior.

task-4583314

Forward-Port-Of: odoo/odoo#234513
Forward-Port-Of: odoo/odoo#203454

Marketplace orders with discounted tax-exclusive lines could not match the
platform total: Odoo accumulated a small rounding residue vs Shopee's
total_amount / Lazada's order price.

sale_shopee
-----------
- Use model_discounted_price as price_unit (discount=0) instead of a
  percentage discount.
- Rename _recompute_subtotal to _compute_subtotal to derive tax-exclusive
  subtotals from tax-inclusive totals (aligned with sale_lazada).
- Add _compute_reconciled_line_specs: price-include taxes keep the discounted
  unit price; tax-exclusive taxes use the nominal rounded tax-exclusive unit.
- In _create_order_from_data, append a tax-free "Shopee Amount Adjustment"
  line for any residue vs Shopee total_amount.
- Add a dedicated shipping line with fiscal-position-mapped taxes.
- Structure SO line descriptions (SKU, promotion, original price) via
  _build_item_description.
- Consolidate tests with build_order_mock(**extra); tax fixtures use an
  explicit tax group where required (Odoo 19+).

sale_lazada
-----------
- Port the same reconciliation model: reconciled line specs, discount=0 with
  discounted unit from paid_price, shipping line from shipping_fee, order-level
  tax-free "Lazada Amount Adjustment" vs order price.
- Group by SKU: _build_item_description (SKU, voucher, original price);
  skip all-canceled SKU buckets.
- Tests: build_order_mock(), same tax fixture pattern as sale_shopee.

task-6112062

Currently, an error occurs when loading sample data in work orders.

**Steps to Reproduce:**

 - Install `mrp_workorder` without demo data.
 - Go to `Settings` > `Users & Companies` > `Groups` and open the `Manage Work Order Operations` group.
 - Add the `administrator` to the `users` list.
 - Open the `Shop Floor` and, if you see `Activate your Work center`, click on it and then click `Configure Later`.
 - Click on `Load Samples`.

`AttributeError: 'NoneType' object has no attribute 'id'`

After this [recent commit], sample data loading in mrp_workorder started linking Quality Points 
to a specific BOM line [1] using the provided sample data [2]. However, some sample entries 
contain None [3] as the bom_line, which raises the error [1].

This commit ensures that the BOM line ID is only set when a BOM line exists.

[recent commit]: https://github.com/odoo/enterprise/commit/c2a3e89c3ff5bc201bf7307b3b7d322d7bd0eecc

[1]- https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L233

[2]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L251

[3]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L242

sentry-7475493233

Forward-Port-Of: odoo/enterprise#117037

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

Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed

1. Install eCommerce and Sales
2. Go to Settings > Website > Delivery and enable "Click & Collect"
3. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Website > Configuration > Delivery Methods and open "Pick up in store", set YourCompany as warehouse and publish it
6. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units
7. Log out
8. Go to the shop, add product "Office Lamp" to the cart and checkout
9. Fill in the address form and continue checkout
10. Select "Pick up in store" as delivery method and select a location
11. Confirm the order and pay with Demo
12. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order
13. Open the related delivery with the smart button and validate it
14. No delivery order confirmation was sent to the customer (check emails)

Issue:
Confirming an order with a "Pick up in store" delivery method replaces the `partner_shipping_id` of the sale order with an archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/delivery/models/sale_order.py#L178-L192
which updates the `partner_id` of the related `stock.picking` with the archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/sale_stock/models/sale_order.py#L130-L132
This will unsubscribe the old `partner_id` on the `stock.picking` and try to subscribe the archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/stock/models/stock_picking.py#L1120-L1125
Because the partner we want to subscribe is archived, he will be filtered out and the subscribe action will have no effect, preventing him from receiving the delivery confirmation
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/mail/models/mail_thread.py#L4367-L4369

Solution:
Subscribe the parent of the archived partner when we write a `partner_id` on pickings with "in_store" `delivery_type`. This ensures the unarchived partner is subscribed to the picking allowing him to receive the mail confirmation.

opw-6095396

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#262591

Steps to produce:
---
- Install website_sale module.
- Enable `Comparison Price` from settings.
- Create a product with sales price = 25 and compare price = 25.
- Go to the shop page and search for the product.

Issue:
---
- The strikethrough appears on the compare price (25) even when the compare price equals the sales price.
- The strikethrough should only appear when the compare price is strictly greater than the sales price.

Root cause:
---
- In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal.

Solution:
---
- Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2].

Before:
---
<img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" />

After:
---
<img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" />


[1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834
[2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346

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

Forward-Port-Of: odoo/odoo#262434

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999