## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#120865
Forward-Port-Of: odoo/enterprise#116430

Currently, an error occurs when a user tries to send an sms to a visitor.

**Steps to Reproduce:**
 - Install `website_crm_sms` without demo data.
 - Go to `Website` > `Edit`, drag and drop another `Form` block.
 - Configure the form action to `Create an Opportunity` and `save`.
 - Fill in the required fields, including phone number and `Submit` the form.
 - Go to `Website` > `Reporting` > `Visitors` and click the `SMS` button on the visitor record.

`AttributeError: 'website.visitor' object has no attribute 'phone'`

After [this commit], which removed the mobile field from res.partner along with all related views, 
then it was updated to access the phone number from the website visitor.
When a user creates an opportunity through the website and then tries to send an sms from the 
corresponding visitor record, it raises an error [1] because it attempts to access the phone field on 
website.visitor. when an anonymous (non-logged-in) user creates an opportunity, clicking the
 sms button on the corresponding visitor record triggers error here [2].

This commit ensures that the correct mobile field is accessed from the website visitor.

[this commit]: https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

[1]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L13

[2]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L20

sentry-7550340909

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

Forward-Port-Of: odoo/odoo#270118

Steps to produce:
---
- Install `website_sale_loyalty`.
- Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`.
- Create a new discount & loyalty program > set program type as `promotions`.
- Under Rewards, select `Free Shipping` as the reward type.
- Create a product with a price of 1000 and publish it.
- Add the product to the cart from the website.
- Observe that free shipping is automatically applied on cart.
- Attempt to remove the free shipping reward from the cart.

Issue:
---
- Free shipping (and similarly, free product rewards) cannot be removed from the cart once applied.

Root cause:
---
- At [1], the `website_sale_loyalty_delete` context is only passed when the reward type is `discount`. As a result, for free shipping and free product rewards, the context is not set. At [2], the order line is removed, but the reward is not added to `disabled_auto_rewards`. The `_auto_apply_rewards` method runs immediately afterward, detects the missing reward, and re-applies it automatically.

Fix:
---
- Since there are three reward types (discount, free shipping, and free product), the condition restricting the context to only discount rewards should be removed.

[1]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order.py#L179
[2]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order_line.py#L15-L23

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

Forward-Port-Of: odoo/odoo#261732

Steps to reproduce:
1. Open the Project application and open any project.
2. Filter the tasks by milestone (milestone deadlines appear as expected in the kanban view).
3. Open any task form view.
4. Click the browser's back button (or simply refresh the page while on the task kanban view).

Issue:
Milestone deadline dates disappear from the task Kanban cards and headers after navigating back or reloading.

Why this happens:
When hitting the browser back button or refreshing, the web client's router state recovery workflow executes (`loadRouterState` -> `loadState` -> `doAction` -> `_executeActWindowAction`). During this flow, `_getActionParams` checks if it can reuse the cached `lastAction`. However, due to a safety condition introduced in commit ab26f95893 to prevent embedded action showing across different projects, the router falls back to generating a fresh action request via `state.action`.

This forces `_loadAction` to fetch the action definition from the database. Because the original base action window `act_project_project_2_project_task_all` lacks the `display_milestone_deadline` key inside its default context dictionary, the reloaded view is rendered without the flags required by the frontend to display milestone deadlines.

opw-6283514

Forward-Port-Of: odoo/odoo#269781

## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:

1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />

## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
    - Any name
    - Model: *Contact*
    - Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**

## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.

https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17

related: https://github.com/odoo/enterprise/pull/115492

opw-6219824

Forward-Port-Of: odoo/odoo#265163

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

Forward-Port-Of: odoo/enterprise#115492

Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased.

For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`.

However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision.

This is inconsistent with sales: sale order lines preserve very small unit prices correctly.


**Current behavior before PR:**

A product with `standard_price = 0.001235` keeps that value on the product form.

When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost.

The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line.

**Desired behavior after PR is merged:**

Purchase order lines preserve the computed unit price precision, just like sale order lines already do.

A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision.

---

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

Forward-Port-Of: odoo/odoo#269413
Forward-Port-Of: odoo/odoo#267941

# How to reproduce
- Create an Event registration
- Add a follower
- Click on the enveloppe icon next to the sender's name in the chatter

# The problem
A traceback appears

# Cause of the issue
When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105

But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing :
https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27

opw-6178443

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

Forward-Port-Of: odoo/odoo#265263

When moving an order (Order A) to a table that already has an order (Order B), the merged order only reprints Order B's products. The products from Order A are missing from the preparation reprint.

Steps to reproduce:
-------------------
* Open a POS session on a Restaurant POS
* Create an order (Order A) for Table 1
* Create a second order (Order B) for Table 2
* Transfer/Merge Order A to Table 2
* Reprint the preparation order

> Observation:
Only the products that were already on Table 2 (Order B) appear on the reprint. Products from Order A are missing.

Why the fix:
------------
mergeOrders correctly transfers kitchen history
(last_order_preparation_change.lines) via handlePreparationHistory, but does not update uiState.lastPrints on the destination order. The reprint button uses lastPrints.at(-1) when there are no pending changes, so it only shows the destination order's last print batch — ignoring the merged lines entirely.

Implementation:
After the merge loop, build a consolidated lastPrints entry from the destination order's last_order_preparation_change.lines (which now contains lines from both orders) and push it onto
destOrder.uiState.lastPrints so that reprint reflects the full merged state.

opw-6060684

Forward-Port-Of: odoo/odoo#270311
Forward-Port-Of: odoo/odoo#256309

There's a few problems with kits and cogs
This PR fixes them and unskips most tests 
of the test class.

**Problems:**
- Problem 1 multiple steps delivery 
  - steps to reproduce: 
    - activate 3 steps delivery 
    - create 2 storable products 'comp A' and 'comp B' 
with category standard perpetual
    - for both : set a cost of 10 and on on hand quantity
    - create a storable kit product with category standard perpetual 
    - create a kit bom for the kit product with 1 comp A and 1 comp B
    - confirm a SO for 1 quantity of the kit prod
    - validate only first delivery
    - confirm invoice 
  - Current behaviour: 
 No cogs line 
  - expected behaviour : 
There should be cogs for 20$
- Problem 2 multiple kits in Bom : 
  - steps to reproduce: 
    - (multiple steps delivery not needed)
    - use same products as for problem 1 but, in the Bom, set
    the number of kit products produced to 2
    - confirm a SO for 2 quantity of the kit prod
    - validate all pickings
    - confirm invoice 
  - Current behaviour: 
 Cogs have a value of 10$
  - expected behaviour : 
There should be cogs for 20$
- Problem 3: fifo comp
  - steps to reproduce: 
    - with 1 step delivery
    - create a storable product 'comp A' with fifo perpetual
    category
    - Confirm a PO and validate receipt for 1 comp A at 10
    - Confirm a PO and validate receipt for 1 comp A at 20
    - create a storable product 'kit' with fifo perpetual categ
    - create a kit bom for the kit product with 1 comp A
    - confirm SO for 2 kit
    - deliver 1 quantity and create backorder
    - confirm invoice for 1 
    - COGS line are created for 10$ (as expected)
    - deliver the backorder
    - confirm invoice for 1
  - Current Behaviour: 
  Cogs are created for 15$
  - Expected Behaviour: 
  Cogs should be created for 20$

**Cause of the issues:**
To compute the price_unit used for the cogs we call 
_get_cogs_value()
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/stock_account/models/account_move.py#L122
What we want is the price unit for 1 unit of the kit product
So we want : 
sum(unit price of each comp * quantity of comp in bom)/ quantity of kit in bom
What is done for now : 
Inside the sale_mrp override, for each component of 
the bom we call _get_price_unit() on its move and 
add the value to 'average_price_unit' and then divide
by the quantity of the kit product in the bom
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/account_move.py#L38-L42
Inside the sale_mrp override of _get_price_unit() 
we return _get_kit_price_unit() called on the move,
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/sale_mrp/models/stock_move.py#L15
Inside _get_kit_price_unit(), the variable 'component_qty_per_kit', 
contains the quantity of each component as recorded in the bom 
times the valued quantity (sale order line quantity).
For each comp :  
    - we store the return value of _get_price_unit 
called on its moves in 'price_unit'.
    - we add to 'total_price_unit': 
    price_unit * component_qty_per_kit/ the kit qty in the bom
we then return total_price_unit / valued quantity
So we actually return:
sum(unit price of each comp * quantity of comp in bom* 
valued quantity)/ (quantity of kit in bom * valued quantity)
which is equal to:
sum(unit price of each comp *quantity of comp in bom)
/ quantity of kit in bom
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/mrp_account/models/stock_move.py#L40-L44
Problem 1 is caused by the fact that _get_price_unit()
will return 0 if there's only internal moves because
they have a value of 0.
(The problem does not happen with a single component
cause then the fallback on the super method is correct, but 
with multiple comp the super method also returns 0
because _get_cogs_price_unit returns 0 when more than 
one product).
Problem 2 is caused by the fact that we divide by the 
quantity of the kit in the bom (kit_bom.product_qty) here 
(inside _get_kit_price_unit) and again inside _get_cogs_value
as mentionned before.

Problem 3 happens because there is no mechanism 
to account for already posted cogs inside the sale_mrp 
override of _get_cogs_value(), as qty_invoiced
is computed but never used
https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/sale_mrp/models/account_move.py#L31

**Fix** 
As regards to the super methods (so non kit scenario),
_get_cogs_value() is used to : 
  -  use original invoice if needed
  - use standard price of the product if no moves
  - deduct already posted cogs 
  - calls get _get_cogs_price_unit() to compute price_unit 
based on the moves

All of this is also wanted for kits and don't need adaptation, 
therefore the override should be on the _get_cogs_price_unit
where we do need a different behaviour when the product is a kit
Doing this we benefit from the 'already posted mechanism' 
from _get_cogs_value which solves problem 3

Additionally, instead of calling get_price_unit we can directly 
call the super method _get_cogs_price_unit as we have 
already computed all the components quantities needed 
for our computation and therefore don't need 
_get_kit_price_unit to recompute all of this.
Also, _get_cogs_price_unit will fall back on the product
standard price if the move has no value which solves 
problem 1.
That will also prevent dividing twice by the quantity 
of kit product in the bom (bom.product_qty) 
which solves problem2.

**Tests:**
Out of the 9 existing tests of the class (that were skipped
before this PR) and after adapation to v19 valuation : 
- 2 succeeded before and after the fix : this PR unskips them
- 5 failed before the fix and now suceed with the fix : this PR 
unskips them 
- 2 failed before the fix and after the fix, they were let 
skipped
In addition, 2 tests were added to cover problem 1 and 3
(problem 2 is covered in test test_sale_mrp_kit_bom_cogs)

Forward-Port-Of: odoo/odoo#270675
Forward-Port-Of: odoo/odoo#270075

**Steps to reproduce on a new db:**
(bug also reproducable on runbot but the impact 
is less easy to compute because of influence of other
existing companies)

- create a new company as company 2 and use the existing 
default company as company 1.
- create a warehouse for both company
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).
- for both comp, in settings for inventory valuation set 
'periodic' and for periodic valuation set 'daily'

From company 1 : 
- create a storable product with standard price method and 
set a cost of 30
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 30 
  - the variation lines have a balance of 30
  - all of this is expected

From company 2 :
- change the cost of the product to 10
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 10 
  - the variation lines have a balance of 10
  - all of this is expected
 
From any company :
- navigate to 'scheduled actions' and select the action 
'Stock Account: Inventory Valuation Closing'
- click on 'Run Manually'
- navigate to 'inventory valuation'

**Current behavior:**
with company 1 selected :
  - the initial balance is now 30 
  - ending stock still 30
  - no variation lines
  - the initial balance was correctly increased by the closing entry

with company 2 selected: 
  - the initial balance is now 40
  - the ending stock is still 10
  - the variation lines credit 30 in stock valuation

In company 2 the closing entry debitted 40 in stock valuation 
instead of 10 which increased the initial balance to 40 instead of 10

If you open the journal items you'll find the closing amls have a 
balance of 40 instead of 10

**Cause of the issue:**
The _cron_post_stock_valuation() method 
calls action_close_stock_valuation() on both companies
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L143-L144

This methods calls _action_close_stock_valuation
with a context modified with only self.env.company.ids
in 'allowed_company_ids'
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L56

This is needed because inside stock_value() we use 
the total value of the product 
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L92
which will be the sum of the values of the product 
for each company inside allowed_company_id
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/product.py#L274
So in case action_close_stock_valuation() was called from 
the 'generate entry' button from the inventory valuation view
we need only the main company selected to be in the
'allowed_company_ids' so that the inventory value is computed 
based only on this company (as is the accounting value).

The problem is that this does not work when calling the 
method from _cron_post_stock_valuation because then
there is no 'allowed_company_ids' in the context (because it was
called from _process_job() with a new env).
so self.env.company will be the company of the user 
which will be company 1.
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/odoo/orm/environments.py#L243

Therefore when _action_close_stock_valuation will be 
called on company 2, in the context, allowed_company_ids 
will be company 1. Then, when computing 'products', with_company() 
will add self (company 2) to the context.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L151-L152
So stock_value will return the sum of the total_value 
of each product for company 1 and company 2 which is 40 (instead 
of 10 for just company 2)
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L242

We then create the closing accounting entry to match the 
accounting value with the stock value, which explains why 
the new initial accounting balance of company 2 is 40.

**fix:**
We set the context using self instead of self.env.companies
This makes more sense as both in the cron use case and 
the generate entry use case the stock value we want is the 
one of the company in self. 
- In cron use case, it's obvious as the method is called 
in a for loop on each company
- In the generate entry use case, self will also be the main 
company, because it's called, in actionGenerateEntry, 
on this.companyId 
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L75
which is computed based on the get_report_values
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L21
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L28-L30
Which returns the main company
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/report/stock_valuation_report.py#L29


Most importantly, this is also aligned with how the accounting 
values are computed.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L103-L105


opw-6237402

Forward-Port-Of: odoo/odoo#269152
Forward-Port-Of: odoo/odoo#266932

Steps to reproduce:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#120467
Forward-Port-Of: odoo/enterprise#116906

**Steps to reproduce:**
* Install the **l10n_cl_edi** module.
* Go to **Accounting → Configuration → CAFs**, create a new CAF, and upload a valid CAF [XML](https://www.odoo.com/mail/message/1097235975) file.
* Create a new **Purchase Journal** with **Use Documents** enabled.
* Create a vendor bill using this journal.
* Set the **Document Type** to **46 - Liquidación-Factura Electrónica**.
* Confirm the vendor bill.

**Observed behavior:**
* The Send button is not visible on the confirmed vendor bill despite the DTE being generated and `l10n_cl_dte_status` being set to `not_sent`.

**Cause:**
* `_compute_display_send_button` in `account` only returns `True` for sale documents (`is_sale_document()`), so the "Send" button — which opens the Send & Print dialog containing the "Send to SII" option — was never shown on vendor bills.
* `_get_move_constraints` in `account.move.send` unconditionally adds a `not_sale_document` constraint for non-sale documents, blocking the Send & Print dialog from processing vendor bills even if the button were visible.
* The cron's `cron_run_sii_workflow` only processes moves with `l10n_cl_dte_status = 'ask_for_status'`, skipping moves still in `not_sent` state.

**Fix:**
* Override `_compute_display_send_button` in `l10n_cl_edi` to also show the "Send" button on posted moves with `l10n_cl_dte_status == 'not_sent'`, matching the pattern used by `l10n_br_edi`.
* Override `_get_move_constraints` in `l10n_cl_edi` to remove the `not_sale_document` constraint for Chilean purchase documents with `not_sent` status, matching the pattern used by `l10n_br_edi`.

**REF**
 During this [refactor](https://github.com/odoo/enterprise/pull/103427/changes/f5617ecf7584cf019897408df94b002622f48d9d), these two methods were inadvertently missed and were not overridden 

opw-6300571

Currently, an error occurs when a user tries to send an sms to a visitor.

**Steps to Reproduce:**
 - Install `website_crm_sms` without demo data.
 - Go to `Website` > `Edit`, drag and drop another `Form` block.
 - Configure the form action to `Create an Opportunity` and `save`.
 - Fill in the required fields, including phone number and `Submit` the form.
 - Go to `Website` > `Reporting` > `Visitors` and click the `SMS` button on the visitor record.

`AttributeError: 'website.visitor' object has no attribute 'phone'`

After [this commit], which removed the mobile field from res.partner along with all related views, 
then it was updated to access the phone number from the website visitor.
When a user creates an opportunity through the website and then tries to send an sms from the 
corresponding visitor record, it raises an error [1] because it attempts to access the phone field on 
website.visitor. when an anonymous (non-logged-in) user creates an opportunity, clicking the
 sms button on the corresponding visitor record triggers error here [2].

This commit ensures that the correct mobile field is accessed from the website visitor.

[this commit]: https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

[1]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L13

[2]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L20

sentry-7550340909

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

Forward-Port-Of: odoo/odoo#270118

Step to reproduce:
1. Install `website_link`
2. Open Website > Site > Link Tracker
3. Type in text into any pre-defined field (Campaign, Medium, Source)
4. Observe that the input is not showing all the typed characters

Issue:
- It's randomly removing characters, for example, type "1234567890" and observe

Cause:
- SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user.

Solution:
- Update searchValue immediately on every raw input event and keep only the search callback debounced.
- Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back 
  to the selected choice label instead of staying visually cleared.

opw-6000540

---

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

Forward-Port-Of: odoo/odoo#267974
Forward-Port-Of: odoo/odoo#255819

Steps to reproduce:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#120467
Forward-Port-Of: odoo/enterprise#116906

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created,
`_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies
Especially `_compute_is_reconciled`
But checked as been replaced by `review_state`
This FW port will use an update on the `review_state` instead of the `checked`

A user with "Invoicing & Banks" rights lacks the
`account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/odoo#270080

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()`
This function creates a balancing line and triggers `move._compute_checked()` to update dependencies

However, `move.checked` requires `_is_user_able_to_review()` to be True
A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as checked, preventing dependencies from computing correctly
Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/enterprise#120217
Forward-Port-Of: odoo/enterprise#118023

Steps to reproduce:
1. Open the Project application and open any project.
2. Filter the tasks by milestone (milestone deadlines appear as expected in the kanban view).
3. Open any task form view.
4. Click the browser's back button (or simply refresh the page while on the task kanban view).

Issue:
Milestone deadline dates disappear from the task Kanban cards and headers after navigating back or reloading.

Why this happens:
When hitting the browser back button or refreshing, the web client's router state recovery workflow executes (`loadRouterState` -> `loadState` -> `doAction` -> `_executeActWindowAction`). During this flow, `_getActionParams` checks if it can reuse the cached `lastAction`. However, due to a safety condition introduced in commit ab26f95893 to prevent embedded action showing across different projects, the router falls back to generating a fresh action request via `state.action`.

This forces `_loadAction` to fetch the action definition from the database. Because the original base action window `act_project_project_2_project_task_all` lacks the `display_milestone_deadline` key inside its default context dictionary, the reloaded view is rendered without the flags required by the frontend to display milestone deadlines.

opw-6283514

Forward-Port-Of: odoo/odoo#269781

The '/my/counters' route is hit a lot of times on big databases like odoo.com

One thing it does is a `self.env['documents.document].search_count([])`

With this commit, we use a subquery for the folder access instead of the current LEFT JOIN.
This ok since the number of folders is typically small compared to regular documents and the query is fast since it can use the index on 'type'

Before as portal user
------

2x Seq Scan

```
 Aggregate  (cost=1900290.73..1900290.74 rows=1 width=8) (actual time=282.271..282.276 rows=1 loops=1)
   Buffers: shared hit=66629
   ->  Hash Left Join  (cost=41649.94..1900044.55 rows=98472 width=0) (actual time=184.202..282.267 rows=3 loops=1)
         Hash Cond: (documents_document.folder_id = documents_document__folder_id.id)
         Filter: ((hashed SubPlan 2) OR ((documents_document.owner_id = 6) AND ((documents_document.shortcut_document_id IS NULL) OR (documents_document.shortcut_document_owner_id = 6))) OR (((documents_document.access_via_link)::text = ANY ('{edit,view}'::text[])) AND (documents_document.folder_id IS NOT NULL) AND ((hashed SubPlan 4) OR ((documents_document__folder_id.owner_id = 6) AND ((documents_document__folder_id.shortcut_document_id IS NULL) OR (documents_document__folder_id.shortcut_document_owner_id = 6)))) AND (documents_document.is_access_via_link_hidden IS NOT TRUE)))
         Rows Removed by Filter: 28085
         Buffers: shared hit=66629
         ->  Seq Scan on documents_document  (cost=0.00..1857903.54 rows=187073 width=26) (actual time=0.022..109.288 rows=28088 loops=1)
               Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))) OR (((access_via_link)::text = ANY ('{edit,view}'::text[])) AND (folder_id IS NOT NULL) AND (is_access_via_link_hidden IS NOT TRUE))))
               Rows Removed by Filter: 342576
               Buffers: shared hit=33313
               SubPlan 2
                 ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.008..0.009 rows=0 loops=2)
                       Buffers: shared hit=6
                       ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.008..0.008 rows=0 loops=2)
                             Index Cond: (partner_id = 7)
                             Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:16:38'::timestamp without time zone))
                             Buffers: shared hit=6
                       ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (never executed)
                             Index Cond: (id = documents_access.document_id)
                             Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
         ->  Hash  (cost=37016.64..37016.64 rows=370664 width=16) (actual time=164.521..164.521 rows=370664 loops=1)
               Buckets: 524288  Batches: 1  Memory Usage: 17824kB
               Buffers: shared hit=33310
               ->  Seq Scan on documents_document documents_document__folder_id  (cost=0.00..37016.64 rows=370664 width=16) (actual time=0.005..100.491 rows=370664 loops=1)
                     Buffers: shared hit=33310
         SubPlan 4
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.003..0.003 rows=0 loops=1)
                 Buffers: shared hit=3
                 ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.002..0.003 rows=0 loops=1)
                       Index Cond: (partner_id = 7)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:16:38'::timestamp without time zone))
                       Buffers: shared hit=3
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (never executed)
                       Index Cond: (id = documents_access_1.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
 Planning:
   Buffers: shared hit=69
 Planning Time: 1.708 ms
 Execution Time: 282.344 ms
```

After  as portal user
-----

Only 1x Seq Scan
```
Aggregate  (cost=2004948.33..2004948.34 rows=1 width=8) (actual time=116.161..116.165 rows=1 loops=1)
   Buffers: shared hit=37942
   ->  Seq Scan on documents_document  (cost=145660.16..2004490.36 rows=183187 width=0) (actual time=24.635..116.155 rows=3 loops=1)
         Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))) OR (((access_via_link)::text = ANY ('{edit,view}'::text[])) AND (hashed SubPlan 5) AND (is_access_via_link_hidden IS NOT TRUE))))
         Rows Removed by Filter: 370661
         Buffers: shared hit=37942
         SubPlan 2
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.008..0.009 rows=0 loops=1)
                 Buffers: shared hit=3
                 ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.008..0.008 rows=0 loops=1)
                       Index Cond: (partner_id = 7)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:15:10'::timestamp without time zone))
                       Buffers: shared hit=3
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (never executed)
                       Index Cond: (id = documents_access.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
         SubPlan 5
           ->  Index Scan using documents_document__type_index on documents_document documents_document_1  (cost=0.42..145625.73 rows=13772 width=4) (actual time=11.688..11.689 rows=0 loops=1)
                 Index Cond: ((type)::text = 'folder'::text)
                 Filter: ((hashed SubPlan 4) OR ((owner_id = 6) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 6))))
                 Rows Removed by Filter: 28198
                 Buffers: shared hit=4629
                 SubPlan 4
                   ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.002..0.002 rows=0 loops=1)
                         Buffers: shared hit=3
                         ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.001..0.002 rows=0 loops=1)
                               Index Cond: (partner_id = 7)
                               Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 10:15:10'::timestamp without time zone))
                               Buffers: shared hit=3
                         ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (never executed)
                               Index Cond: (id = documents_access_1.document_id)
                               Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
 Planning:
   Buffers: shared hit=56
 Planning Time: 1.544 ms
 Execution Time: 116.216 ms
```

Before as internal user
--------
```
Aggregate  (cost=1902165.43..1902165.44 rows=1 width=8) (actual time=332.919..332.925 rows=1 loops=1)
   Buffers: shared hit=69223 read=370
   ->  Hash Left Join  (cost=41649.94..1901908.04 rows=102955 width=0) (actual time=176.179..332.325 rows=10040 loops=1)
         Hash Cond: (documents_document.folder_id = documents_document__folder_id.id)
         Filter: ((hashed SubPlan 2) OR ((documents_document.owner_id = 1054906) AND ((documents_document.shortcut_document_id IS NULL) OR (documents_document.shortcut_document_owner_id = 1054906))) OR (((documents_document.access_internal)::text = ANY ('{view,edit}'::text[])) AND ((documents_document.company_id = 1) OR (documents_document.company_id IS NULL))) OR (((documents_document.access_via_link)::text = ANY ('{view,edit}'::text[])) AND (documents_document.folder_id IS NOT NULL) AND ((hashed SubPlan 4) OR ((documents_document__folder_id.owner_id = 1054906) AND ((documents_document__folder_id.shortcut_document_id IS NULL) OR (documents_document__folder_id.shortcut_document_owner_id = 1054906))) OR (((documents_document__folder_id.access_internal)::text = ANY ('{view,edit}'::text[])) AND ((documents_document__folder_id.company_id = 1) OR (documents_document__folder_id.company_id IS NULL)))) AND (documents_document.is_access_via_link_hidden IS NOT TRUE)))
         Rows Removed by Filter: 27228
         Buffers: shared hit=69223 read=370
         ->  Seq Scan on documents_document  (cost=0.00..1859756.86 rows=190950 width=35) (actual time=15.029..155.718 rows=37268 loops=1)
               Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))) OR (((access_via_link)::text = ANY ('{view,edit}'::text[])) AND (folder_id IS NOT NULL) AND (is_access_via_link_hidden IS NOT TRUE))))
               Rows Removed by Filter: 333396
               Buffers: shared hit=33931 read=370
               SubPlan 2
                 ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.155..7.920 rows=148 loops=2)
                       Buffers: shared hit=1612 read=370
                       ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.110..3.448 rows=200 loops=2)
                             Index Cond: (partner_id = 1800102)
                             Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:17:29'::timestamp without time zone))
                             Buffers: shared hit=192 read=190
                       ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (actual time=0.022..0.022 rows=1 loops=400)
                             Index Cond: (id = documents_access.document_id)
                             Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
                             Rows Removed by Filter: 0
                             Buffers: shared hit=1420 read=180
         ->  Hash  (cost=37016.64..37016.64 rows=370664 width=25) (actual time=157.822..157.823 rows=370664 loops=1)
               Buckets: 524288  Batches: 1  Memory Usage: 21336kB
               Buffers: shared hit=33310
               ->  Seq Scan on documents_document documents_document__folder_id  (cost=0.00..37016.64 rows=370664 width=25) (actual time=0.005..96.730 rows=370664 loops=1)
                     Buffers: shared hit=33310
         SubPlan 4
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.019..0.372 rows=148 loops=1)
                 Buffers: shared hit=991
                 ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.005..0.078 rows=200 loops=1)
                       Index Cond: (partner_id = 1800102)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:17:29'::timestamp without time zone))
                       Buffers: shared hit=191
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (actual time=0.001..0.001 rows=1 loops=200)
                       Index Cond: (id = documents_access_1.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
                       Rows Removed by Filter: 0
                       Buffers: shared hit=800
 Planning:
   Buffers: shared hit=69 read=8
 Planning Time: 2.116 ms
 Execution Time: 333.013 ms
```

After as internal user
--------
```
Aggregate  (cost=2006950.17..2006950.18 rows=1 width=8) (actual time=157.117..157.121 rows=1 loops=1)
   Buffers: shared hit=39918
   ->  Seq Scan on documents_document  (cost=145798.74..2006482.26 rows=187165 width=0) (actual time=16.595..156.590 rows=10040 loops=1)
         Filter: ((active IS TRUE) AND ((hashed SubPlan 2) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))) OR (((access_via_link)::text = ANY ('{view,edit}'::text[])) AND (hashed SubPlan 5) AND (is_access_via_link_hidden IS NOT TRUE))))
         Rows Removed by Filter: 360624
         Buffers: shared hit=39918
         SubPlan 2
           ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.019..1.016 rows=148 loops=1)
                 Buffers: shared hit=991
                 ->  Index Scan using documents_access__partner_id_index on documents_access  (cost=0.43..105.55 rows=103 width=9) (actual time=0.012..0.262 rows=200 loops=1)
                       Index Cond: (partner_id = 1800102)
                       Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:16:29'::timestamp without time zone))
                       Buffers: shared hit=191
                 ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id  (cost=0.42..2.44 rows=1 width=9) (actual time=0.004..0.004 rows=1 loops=200)
                       Index Cond: (id = documents_access.document_id)
                       Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access.role)::text = ANY ('{view,edit}'::text[])))
                       Rows Removed by Filter: 0
                       Buffers: shared hit=800
         SubPlan 5
           ->  Index Scan using documents_document__type_index on documents_document documents_document_1  (cost=0.42..145763.43 rows=14124 width=4) (actual time=0.429..14.916 rows=4625 loops=1)
                 Index Cond: ((type)::text = 'folder'::text)
                 Filter: ((hashed SubPlan 4) OR ((owner_id = 1054906) AND ((shortcut_document_id IS NULL) OR (shortcut_document_owner_id = 1054906))) OR (((access_internal)::text = ANY ('{view,edit}'::text[])) AND ((company_id = 1) OR (company_id IS NULL))))
                 Rows Removed by Filter: 23573
                 Buffers: shared hit=5617
                 SubPlan 4
                   ->  Nested Loop  (cost=0.85..357.41 rows=99 width=4) (actual time=0.007..0.390 rows=148 loops=1)
                         Buffers: shared hit=991
                         ->  Index Scan using documents_access__partner_id_index on documents_access documents_access_1  (cost=0.43..105.55 rows=103 width=9) (actual time=0.003..0.074 rows=200 loops=1)
                               Index Cond: (partner_id = 1800102)
                               Filter: ((expiration_date IS NULL) OR (expiration_date >= '2026-06-18 12:16:29'::timestamp without time zone))
                               Buffers: shared hit=191
                         ->  Index Scan using documents_document_pkey on documents_document documents_access__document_id_1  (cost=0.42..2.44 rows=1 width=9) (actual time=0.001..0.001 rows=1 loops=200)
                               Index Cond: (id = documents_access_1.document_id)
                               Filter: (((access_via_link)::text <> 'none'::text) OR ((documents_access_1.role)::text = ANY ('{view,edit}'::text[])))
                               Rows Removed by Filter: 0
                               Buffers: shared hit=800
 Planning:
   Buffers: shared hit=56
 Planning Time: 1.569 ms
 Execution Time: 157.171 ms
```

portal user
before https://explain.dalibo.com/plan/e1e755fg7bb26a21
after https://explain.dalibo.com/plan/hb5fa1d201ff164g

internal user with few documents access
before https://explain.dalibo.com/plan/f753bf2aa244dg63
after https://explain.dalibo.com/plan/538dg5ecb120ch84

internal user with *lots* of documents access
before https://explain.dalibo.com/plan/cf76h84537f7ge4a
after https://explain.dalibo.com/plan/45317a5e3168c5bc

## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:

1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />

## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
    - Any name
    - Model: *Contact*
    - Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**

## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.

https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17

related: https://github.com/odoo/enterprise/pull/115492

opw-6219824

Forward-Port-Of: odoo/odoo#265163

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

Forward-Port-Of: odoo/enterprise#115492

# How to reproduce
- Create an Event registration
- Add a follower
- Click on the enveloppe icon next to the sender's name in the chatter

# The problem
A traceback appears

# Cause of the issue
When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105

But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing :
https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27

opw-6178443

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

Forward-Port-Of: odoo/odoo#265263

When moving an order (Order A) to a table that already has an order (Order B), the merged order only reprints Order B's products. The products from Order A are missing from the preparation reprint.

Steps to reproduce:
-------------------
* Open a POS session on a Restaurant POS
* Create an order (Order A) for Table 1
* Create a second order (Order B) for Table 2
* Transfer/Merge Order A to Table 2
* Reprint the preparation order

> Observation:
Only the products that were already on Table 2 (Order B) appear on the reprint. Products from Order A are missing.

Why the fix:
------------
mergeOrders correctly transfers kitchen history
(last_order_preparation_change.lines) via handlePreparationHistory, but does not update uiState.lastPrints on the destination order. The reprint button uses lastPrints.at(-1) when there are no pending changes, so it only shows the destination order's last print batch — ignoring the merged lines entirely.

Implementation:
After the merge loop, build a consolidated lastPrints entry from the destination order's last_order_preparation_change.lines (which now contains lines from both orders) and push it onto
destOrder.uiState.lastPrints so that reprint reflects the full merged state.

opw-6060684

Forward-Port-Of: odoo/odoo#270311
Forward-Port-Of: odoo/odoo#256309

## Description

When loading demo data from **Settings** after installing `l10n_in` without demo data, the `_install_demo` method receives company IDs instead of a `res.company` recordset.

As a result, the following line crashes:

```python
companies.filtered(...)
```

with:

```text
AttributeError: 'int' object has no attribute 'filtered'
```

This PR ensures that the received company IDs are converted into a `res.company` recordset before being processed, allowing demo data to be loaded successfully from the Settings menu.

## Steps to Reproduce

1. Install `l10n_in` **without demo data**.
2. Navigate to **Settings**.
3. Click **Load Demo Data**.

## Current Behavior

Demo data installation fails with:

```text
AttributeError: 'int' object has no attribute 'filtered'
```

## Expected Behavior

Demo data should be installed successfully without raising any exception.

## Solution

Convert the received company IDs into a `res.company` recordset when the argument passed to `_install_demo` is not already a recordset.

A personal outgoing mail server is an `ir.mail_server` that belongs to one user. The
system only lets that user send through it. Mass mailings do not always respect this,
which can cause a few problems:

1. Admins cannot duplicate a personal server. The copy keeps the same owner, and the rule that says one user can own only one server stops the save.
2. In *Email Marketing > Settings*, the "Dedicated Server" picker offers every server, even personal ones. If an admin picks a personal one, all campaigns get stuck. The cron job runs as Odoobot, the personal server rejects it, and the mailing stays in the queue.
3. When no dedicated server is set, the fallback selection can still land on a personal server (for example because its `from_filter` matches the sender). The cron sends through it and gets rejected.


One commit per problem:

1. **mail**: duplicating a personal server now produces a copy with no owner.
2. **mass_mailing**: the picker in the settings hides personal servers. Setting an owner on a server that is already used for mass mailing now raises a clear error that names the campaign blocking the change.
3. **mass_mailing**: personal servers are skipped when the fallback selection runs, so only shared servers are considered.

opw-6086077

Forward-Port-Of: odoo/odoo#261537

In the current code, for each slot, and for each "available"
resource, we check if the resource is available on the slot,
based on availability values. Then, we check the remaining
capacity of that resource. Also, linked resources information
is added when computing the original resource remaining capacity.
If many linked resources exist, this will be done several times
and is not useful.

This commit makes that loop disappear. We now check all resources
at once in terms of availability, and linked resources that could
be selected (in the appointment resources, in the slot resources
(if any restricted resource)) at the same time. Then, the total
capacity is the sum of the resource remaining capacity and the
ones of available linked resources.

Therefore, _slot_availability_is_resource_available is renamed to
_slot_available_resources, as it now takes more than one resource
and returns all resources among 'resources' that are valid on
the slot, based on the availability_values, slot restrictions and
booking lines.

A noticeable difference is mainly seen when using many resources
(and linked resources). For instance, a restaurant with a lot of
small tables will have their slot availability check much shorter.

BENCHMARK, LOCAL (time only, as number of requests does not change)
Only appointment installed

For a restaurant with
- 10 tables of 2
- 5 tables of 2 linked, 2 times
- 10 tables of 4
- 2 table of 2
- time then auto assign

On loading /appointment/id:
~ 3.1s -> ~ 1.6s
On selecting any number of people (1 to 10):
[2s, 2.5s] -> [0.6s, 0.8s]

Task-4144524

Forward-Port-Of: odoo/enterprise#107711

Currently, an error occurs when a user sorts tasks by Planned Date.

**Steps to reproduce:**
 - Install the `project_enterprise` module with demo data.
 - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the 
   tasks by `Planned Date`.

KeyError: 'order'

After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by 
Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. 
However, the planned_date_begin entry does not define an order key [2], which raises 
error when it tries to access order.

This commit ensures that the order key is added with its value for planned_date_begin in 
searchbar sorting.

[recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a

[1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424

[2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11

sentry-7556050938

Currently, an error occurs when a user tries to send an sms to a visitor.

**Steps to Reproduce:**
 - Install `website_crm_sms` without demo data.
 - Go to `Website` > `Edit`, drag and drop another `Form` block.
 - Configure the form action to `Create an Opportunity` and `save`.
 - Fill in the required fields, including phone number and `Submit` the form.
 - Go to `Website` > `Reporting` > `Visitors` and click the `SMS` button on the visitor record.

`AttributeError: 'website.visitor' object has no attribute 'phone'`

After [this commit], which removed the mobile field from res.partner along with all related views, 
then it was updated to access the phone number from the website visitor.
When a user creates an opportunity through the website and then tries to send an sms from the 
corresponding visitor record, it raises an error [1] because it attempts to access the phone field on 
website.visitor. when an anonymous (non-logged-in) user creates an opportunity, clicking the
 sms button on the corresponding visitor record triggers error here [2].

This commit ensures that the correct mobile field is accessed from the website visitor.

[this commit]: https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

[1]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L13

[2]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L20

sentry-7550340909

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

Forward-Port-Of: odoo/odoo#270118

Steps to reproduce:
1. Open the Project application and open any project.
2. Filter the tasks by milestone (milestone deadlines appear as expected in the kanban view).
3. Open any task form view.
4. Click the browser's back button (or simply refresh the page while on the task kanban view).

Issue:
Milestone deadline dates disappear from the task Kanban cards and headers after navigating back or reloading.

Why this happens:
When hitting the browser back button or refreshing, the web client's router state recovery workflow executes (`loadRouterState` -> `loadState` -> `doAction` -> `_executeActWindowAction`). During this flow, `_getActionParams` checks if it can reuse the cached `lastAction`. However, due to a safety condition introduced in commit ab26f95893 to prevent embedded action showing across different projects, the router falls back to generating a fresh action request via `state.action`.

This forces `_loadAction` to fetch the action definition from the database. Because the original base action window `act_project_project_2_project_task_all` lacks the `display_milestone_deadline` key inside its default context dictionary, the reloaded view is rendered without the flags required by the frontend to display milestone deadlines.

opw-6283514

Forward-Port-Of: odoo/odoo#269781

## Issue
In the *Data Recycle* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:

1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="720" height="281" alt="115492" src="https://github.com/user-attachments/assets/567902af-b356-4a0a-8b1e-2ed101a2eba3" />

## Steps to reproduce
1. Install *Data Recycle* (`data_recycle`)
2. In Data Cleaning > Configuration > Recycle Records, create a new rule:
    - Any name
    - Model: *Contact*
    - Filter: *Name contains G* (or anything else that matches some records)
4. Click the *Run Now* button in the upper left corner
5. In Data Cleaning > Recyle Records, group the records by any field (e.g., *Model*)
6. **The name of the group (Contact) is truncated, making it and the record count unreadable. This is due to the sum of Record ID being displayed in the same row, even though that information is irrelevant.**

## Cause
Similarly to related enterprise PR https://github.com/odoo/enterprise/pull/115492, the *Record ID* field of the `data_recycle.record` model uses the default `sum` aggregator.

https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/addons/data_recycle/models/data_recycle_record.py#L17

related: https://github.com/odoo/enterprise/pull/115492

opw-6219824

Forward-Port-Of: odoo/odoo#265163

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

Forward-Port-Of: odoo/enterprise#115492

# How to reproduce
- Create an Event registration
- Add a follower
- Click on the enveloppe icon next to the sender's name in the chatter

# The problem
A traceback appears

# Cause of the issue
When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105

But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing :
https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27

opw-6178443

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

Forward-Port-Of: odoo/odoo#265263

Currently, an error occurs when a user tries to send an sms to a visitor.

**Steps to Reproduce:**
 - Install `website_crm_sms` without demo data.
 - Go to `Website` > `Edit`, drag and drop another `Form` block.
 - Configure the form action to `Create an Opportunity` and `save`.
 - Fill in the required fields, including phone number and `Submit` the form.
 - Go to `Website` > `Reporting` > `Visitors` and click the `SMS` button on the visitor record.

`AttributeError: 'website.visitor' object has no attribute 'phone'`

After [this commit], which removed the mobile field from res.partner along with all related views, 
then it was updated to access the phone number from the website visitor.
When a user creates an opportunity through the website and then tries to send an sms from the 
corresponding visitor record, it raises an error [1] because it attempts to access the phone field on 
website.visitor. when an anonymous (non-logged-in) user creates an opportunity, clicking the
 sms button on the corresponding visitor record triggers error here [2].

This commit ensures that the correct mobile field is accessed from the website visitor.

[this commit]: https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

[1]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L13

[2]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L20

sentry-7550340909

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

Forward-Port-Of: odoo/odoo#270118

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Forward-Port-Of: odoo/enterprise#119255

Steps to produce:
---
- Install the `Rental` and `Subscription` modules.
- Create a rental product and a subscription product.
- Create a sales order containing both products and set a rental period.
- Confirm the sales order.

Issue:
---
- The rental status badge overlaps the subscription status badge.

Root cause:
---
- The rental status badge uses the position-absolute CSS class to place it at the end of the header. When the subscription status badge is also displayed in the same area, both badges are positioned at the same location, causing them to overlap.
- After [commit], this issue is introduced.

Solution:
---
- Replace position-absolute with float-end so the badges remain right-aligned without overlapping.

[commit]: https://github.com/odoo/enterprise/commit/32ab15dc1f26af0e3d510ec859b1ec428068e9b5

Before:
---
<img width="122" height="64" alt="image" src="https://github.com/user-attachments/assets/e6b47c9e-ed59-4a4b-a95c-0318cc43660e" />

After:
---
<img width="175" height="57" alt="image" src="https://github.com/user-attachments/assets/ea98f7a1-67f6-4b2b-b699-1f2cd3376d8f" />

opw-6295212
---

Forward-Port-Of: odoo/enterprise#120660

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101