Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI.

Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there.

The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode.

We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode.

task~5980226

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

Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress.

Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1].

This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled.

This ensures that the autocomplete remains open while the IME composition process completes.

Steps to reproduce:
- Configure a Korean keyboard on an iPhone
- Open a Sale Order
- Focus the search bar
- Type a character, then type a second one to combine them
- The search input value gets reset

[1] #222151

opw-5448385

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

Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#251216
Forward-Port-Of: odoo/odoo#238917

An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change

Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown

Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0

Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked

opw-5931355

Forward-Port-Of: odoo/enterprise#108495

There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.

The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.

This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`

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

Forward-Port-Of: odoo/odoo#246476

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

Forward-Port-Of: odoo/odoo#250115
Forward-Port-Of: odoo/odoo#249482

A component bought from a vendor and
dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to "ordered quantity", the `_eligible_for_stock_account` method will test if the related stock move are dropshipped https://github.com/odoo/odoo/blob/7436e0cfaf8d4b0c0e0390e8d6a3df404ba240f6/addons/stock_account/models/account_move_line.py#L31-L35 The value `is_dropship` is only set at the validation of the stock move. Due to the invoice policy, the receipt is not validated yet.

close #243015
This commit will rather use the helper `_is_dropshipped()` that only rely on the location and not on the state.

This commit also clean and reenable the related tests.

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#249134
Forward-Port-Of: odoo/odoo#245930

Task Adhoc side: 56583
Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view

The error was this one:

Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)

Forward-Port-Of: odoo/enterprise#100457

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#109121
Forward-Port-Of: odoo/enterprise#101579

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

Forward-Port-Of: odoo/enterprise#109103
Forward-Port-Of: odoo/enterprise#103207

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies.

Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted.

This commit:
- Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner.
- Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users.
- Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference.

Task-5912985

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

Forward-Port-Of: odoo/odoo#250651
Forward-Port-Of: odoo/odoo#247961

Steps to reproduce:
- Open the website shop page in edit mode.
- Drag and drop a block in the shop header dropzone.
- Save the page and re-enter edit mode.
- Check the shop header dropzone message.
=> The custom message is replaced by the default one.

Before this commit, `SetupEditorPlugin.cleanForSave()` removed
`data-editor-message` and `data-editor-message-default` on the saved
HTML clone, including custom messages defined in website templates.

This cleanup was originally introduced in `web_editor` in [1]. Since the
builder refactor in [2], website page saves now use the shared
`html_builder` save cleanup flow and wrongly inherited that behavior,
which introduced this regression in website.

This commit removes that cleanup from `html_builder`, as it does not
provide useful value in this save flow and drops custom dropzone
messages.

After this commit, custom dropzone messages are preserved after saving
website pages.

[1]: bab673488e185ddd7792aedecc3870663290fed3
[2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5921283

Forward-Port-Of: odoo/odoo#251579
Forward-Port-Of: odoo/odoo#250874

You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected.

Steps to reproduce
1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b),
model_b.x_studio_test(relation=other_model)`.
2. Create a related field on model_a and click the related icon for the test field.
3. The popover will now be displaying the fields for other_model instead of model_b.

Cause:
This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). 

Solution:
Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`.

opw-ticket 5459944

Forward-Port-Of: odoo/odoo#249185

**Issue:**
The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion checking :
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/odoo/orm/models.py#L5207


This assertion is failing because of the condition related to `is_dropship`. When `is_dropship` is `True`, the `partner_id` is expected to be `p.sale_id.partner_shipping_id.id`
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95
However, for the specific picking record in some cases, `sale_id` is not set
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/sale_stock/models/stock.py#L190
As a result of the current implementation, the [expression](https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95) evaluates to **False**. That False value is then included in the generated list.
**For example** : lot.partner_ids = [2, False, 5, 6]
With the recent changes, when this assignment happens, it **no longer ignores False values**. Instead, during the write process, the ORM internally calls **browse()** on the provided IDs. Since False is not a valid ID, the assertion inside browse() **fails**, this can be seen in the **traceback**.

This shows that when the field is being written, the ORM validates the IDs by calling browse(), and since False is included in the list, the assertion fails.

**Solution:**
To resolve this issue, I have use `mapped. As 'mapped()' will filter out all the empty(False) values from the recordset.

By switching to **mapped()** and returning a recordset instead of a list of IDs, False values are automatically excluded. As a result, no invalid IDs are passed to browse(), and the assertion error is avoided.

I have also added the if `p.is_dropship and p.sale_id.partner_shipping_id` condition because it fallback to the picking partner if there is no sale order partner to use

**Other Optimization:**
I have used `with_prefetch` to fetching `picking_ids`, it is just the purely ORM friendly optimization.
It ensures that all related records are prefetched efficiently across lots. It is not related to the bug above mentioned.

**Traceback:**
```python

   File "/home/odoo/src/odoo/saas-19.1/addons/stock_dropshipping/models/stock.py", line 95, in _compute_partner_ids
    lot.partner_ids = list(p.sale_id.partner_shipping_id.id if p.is_dropship else p.partner_id.id for p in picking_ids)
    ^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1866, in __set__
    self.write(protected_records, value)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 765, in write
    self.write_batch([(records, value)])
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 1553, in write_real
    comodel.browse(
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5202, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 AssertionError: Invalid falsy real id
```
opw: 5922525
upg: 3889582
tgb: 2449

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

Task Adhoc side: 56583
Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view

The error was this one:

Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)

Forward-Port-Of: odoo/enterprise#100457

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#104771

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

**Problem:**
When Billing a dropshipped PO, if the price of the bill 
is changed from the price of the Purchase Order,
the standard price of the product is not updated

**Steps to reproduce:**
- enable the dropshipping settings
- create a storable product with avco perpetual category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 100$ and 
confirm
- validate the dropship move
(- you can check on the product form that the standard price 
is now 100$)
- create a bill for the purchase order
- set the price to 90$ and confirm
- navigate to the product form

**Current behavior:**
The standard price is still 100$

**Expected behavior:**
It should be 90$

**Cause of the issue:**
When we validate the picking, action_done() is called on the moves .
Inside the action_done() override of stock_account, 
after the call to super, set_value is called on is_in 
and is_dropship moves 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L168-L169

Inside _set_value(), 
because the move is dropship, it's going to be added to 
products_to_recompute 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L277-L278

and then we're going to exit this iteration of the for loop. 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L285-L286
so basically we simply call the _update_standard_price() on the product.
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/stock_move.py#L310
Because the product is avco, _update_standard_price is going to call _run_average_batch 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/product.py#L541

The value is not set on the dropship move but it's still used in the computation because for dropship move, we use _get_value()
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/product.py#L382-L383
which will take into account the bills and POs if there are some.

But the problem is that, when we post the invoice we only call set_value on is_in moves
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/account_move.py#L42
So the standard price of our dropshipped product is not updated.

opw-5498878

Forward-Port-Of: odoo/odoo#250067

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109081

This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate).

Current behavior:
Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices.

New behavior:
The XML generation logic has been updated to follow the specific codification required for OSS operations:

1. Invoice Lines (`DettaglioLinee`):
   - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state).
   - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other).

2. Tax Summary (`DatiRiepilogo`):
   - The original foreign tax lines are excluded from the summary.
   - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories.

Implementation details:
- Added `_l10n_it_is_oss_tax` helper to identify OSS taxes.
- Modified `_l10n_it_edi_get_line_values` to split OSS lines.
- Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary.

task-4711509

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#249243
Forward-Port-Of: odoo/odoo#243740

In certain conditions all lines in invoice require a tax. When making
a down payment from an order containing products using fixed price tax,
the corresponding invoice line was created without tax. The issue appear
both when making the down payment from the sale order and from the PoS.

Steps to reproduce:
-------------------
* Create a fixed price tax of 10€
* Create a product with this tax
* Create a sale order with this product and make a downpayment of 10%
> Observation: The down payment line has no tax set.
* Open PoS and make a down payment of 10% for the same order
* Pay and invoice the order
> Observation: The down payment line has no tax set.

Why the fix:
------------
If the tax is required on every invoice line we manually add a 0% tax to
the down payment line to ensure that the invoice is compliant.

At the moment we only add the tax when peppol is activated on the
current company. But the `_require_tax_ids_on_invoice_lines` method can
be overriden by other modules if downpayment lines also require tax.

opw-5853070

Forward-Port-Of: odoo/odoo#251459
Forward-Port-Of: odoo/odoo#247748

Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

Related ticket:
opw-5411034

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

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

Forward-Port-Of: odoo/odoo#250531
Forward-Port-Of: odoo/odoo#249417

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109081

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#109121
Forward-Port-Of: odoo/enterprise#101579

Task Adhoc side: 56583
Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view

The error was this one:

Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)

Forward-Port-Of: odoo/enterprise#100457

When manually changing the tax amount of a vendor bill in the html input field (input above total price), if there is a price difference account move line created, the manual tax inputted will be ignored. This is due to the price difference and associated correcting account move lines having tax_ids. As such, both lines are considered taxable when they should not be and every time we create a price difference line, all taxes are recomputed and manually set tax lines are ignored. This is not the intended behavior because tax for price difference is already accounted for in the tax lines (computed before confirmation of bill) and the price difference lines themselves are just for account balancing and should not be considered taxable.

Steps to reproduce bug on empty DB:
1) Install account and purchase_stock
2) Turn on automatic accounting in settings
3) Create a product category. Set inventory valuation to automated and create and set a price difference account.
4) Create a product. Set the price, set to product category to the created one, and enable track inventory.
5) Create a vendor bill with the product and set a bill date. 
6) Change the price of the product in the bill lines to anything but the original price.
7) Change the tax by clicking on the input field with the pencil icon above amount total to anything but the original tax.
8) Confirm the vendor bill and notice the manually changed tax value revert back to the original value.

Behavior after bug fix:
Upon completing step 8, the manually changed tax value should stay and not be recomputed.

opw-4854669




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

Removing an attachment (coming from a mail template) in the mail
composer wrongly removes it from the template.

- Edit the "Sales: Send Quotation" mail template, add it an attachment
- Go to a draft quotation
- Click on "Send", it will open the mail composer which will use the template. You should see the file you added on the template.
- Now, remove that file from the composer. For instance, for this client you don't want to send it, or you want to replace it or whatever.
- The mail attachment has also been deleted from the template, not only from the current mail.
- Note that you don't need to send it, just deleting it in the composer is enough to have it removed on the template.

Many refactoring were made in `mail` between Odoo 17 and 18, breaking this flow.

Another solution would be to change that in JS side, somehow managing to call `delete()` and not `remove()` in `/mail/[..]/attachment_model.js`. The caller is in `unlink()` in `/mail/[..]/attachment_upload_service.js` which is itself called by `onFileRemove()` from
`/mail/[..]/mail_composer_attachment_list.js`.

That would've kept using the same attachment record as the one in the template without removing it from the template when it's removed from the composer.

The python solution seems more straightforward and since it's creating new attachment no other bugs should arise.

Finally, note that "ghost" attachment are garbage collected through the `_gc_lost_attachments()` autovacuum method, looking for attachment having `res_id=0` and `mail.compose.message` as model.

task-4748058

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109081

Description of the issue/feature this PR addresses:

Related to this task: [4720354](https://www.odoo.com/odoo/project.task/project.task/4720354)
This issue considers a multi company environment, where two companies are set to have different currencies. If an event is created, it belongs to one of these companies. Tickets from either companies can be added to the event's registration, and the end user will see the price for these tickets in the currency of the website, despite some tickets having a different  currency set.

Current behavior before PR:
The registration wizard displays the prices of tickets at face value, i.e. without any conversion. A ticket with its price being 100 euros will be displayed as 100 dollars.

Desired behavior after PR is merged:
The wizard would display the converted amount of the euros tickets in dollars. The 100 euros will be $77.92

Steps to reproduce the issue:
- Create a second company with a currency different than the current company (ex: current company uses dollars, new company uses euros)
- Make two products of type 'event', one for the dollar company and one for the euro company
- Create an event, add two tickets (related to the products)
- Click the register button on the website, see the prices of both tickets, with the modified view, the euro ticket should have its amount converted to the website's currency.

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

*: sale_mrp, sale_purchase_stock

Issue:
Product availability and forecasted lines are not correct when handling multi-warehouse, multi-step deliveries; specifically for manufactured and purchased products with future delivery dates. Product availability for final delivery is "Available" when it should be "Exp."
The forecasted lines show the reserved move as the MO, when it should be the interwarehouse transfer.

This behavior occurs from 17.0 onward, due to [this](https://github.com/odoo/odoo/commit/57d8590) refactor of `_get_forecast_availability_outgoing()` and [this](https://github.com/odoo/odoo/commit/2dad4a5) refactor of StockForecasted.

Assuming we have two warehouses, WH1 and WH2, where WH2 is supplied from WH1, `_get_out_move_reserved_data()` calculates the reserved out quantity, reserved move, and move state. For manufactured/purchased products:
* The products will be reserved from the WH1 MO. WH2 delivery will not recognize the interwarehouse transfer as its in move.
* The forecasted date for the WH2 delivery becomes "Available" when it should match the WH1 transfer date.
* The finished products should be reserved from WH2, which will be transfered from WH1.

This commit refactors `_get_report_lines()` in StockForecasted to encapsulate the reserved stock logic for easier inheriting. It also adjusts the forecast report view to account for case where both reserved move and in move are set.
* We add a check to see if the reserved move has a `production_id` (MRP) or `purchase_line_id` (purchase)
* If true, append the correct in move and reserved move to the forecast line.

Before this commit: 
Product Availability is not consistent (WH2/OUT is "Available" when should match WH1/OUT).

<img width="1915" height="356" alt="image" src="https://github.com/user-attachments/assets/bef9cc3c-b98c-4385-a1bb-aaa4b1e00d71" />

Forecasted report shows the "MO" move as the reserved move.
<img width="1899" height="326" alt="image" src="https://github.com/user-attachments/assets/05a75426-9811-435c-8dad-25a405e8ef2d" />


After this commit:
Multi-warehouse deliveries will have the correct in moves and reserved moves and will reflect correctly in the forecast report.
The products availability will also be consistent, showing "Exp mm/dd/yyyy" for each delivery.

<img width="1910" height="388" alt="image" src="https://github.com/user-attachments/assets/3ee9059e-3202-4409-8dc7-b25222b8f817" />

Forecasted report shows the "IN" move as the reserved move.
<img width="1912" height="294" alt="image" src="https://github.com/user-attachments/assets/e4e4418d-0de7-43fa-8b5a-9267e6a91b15" />


Steps to Reproduce:
* Enable multi-step routes
* Create two warehouses (WH1 and WH2)
  * Both 3-step delivery only
  * WH2 -> resupply from WH1
* WH2 routes:
  * MTO unarchived
  * WH2: Supply product from WH1 -> check "Sales Order Line"
* Create product with routes "Manufacture" and "MTO" + BOM
  * "Buy" and "MTO" for purchases
* Create SO with product
  * show "Route" on SO line
  * set "Route" to "WH2: Supply product from WH1"
* On "Other Info" tab, set:
    * Warehouse -> WH2
    * Shipping Policy -> As Soon as Possible
    * Delivery Date -> +10 days from current date
* Confirm SO
  * 7 delivery orders and 1 MO (or 1 PO) should be made
* For Purchase Only: Confirm the PO
* Go to Delivery Orders
  * show "Product Availability" on the lines
* Products availability for WH2 delivery will be "Available", WH1 delivery will be "Exp mm/dd/yyyy"
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**This is a backport of** https://github.com/odoo/enterprise/commit/f0e2cd2bd9ed89ab2cb961106869088a771d212a


**PROBLEM**
When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`)

**STEP TO REPRODUCE**
1. install the accounting module
2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file.
3. make sure the file will be imported in multiple batches (reduced the batch size if necessary) and click on import.
4. notice how only the first batch was imported.

**CAUSE**
In python,
The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list. (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`)

In JS,
all entry in messages are treated as errors, and the import is interrupted. (see `odoo/addons/base_import/static/src/import_model.js`)

The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message.

**FIX**
Remove the problematic message entry.

opw-4823808
opw-5441739