**Steps to reproduce:**
- create a storable product with a positive quantity
a cost of 10 and average perpetual category
- confirm a SO for 1 quantity, validate delivery
- confirm invoice for 1 (COGS should be 10)
- return the delivery and validate
- create a credit note from the invoice for 1 and confirm
(COGS should be 10)
- return the return and validate
- change the standard price to 100
- create an invoice from the SO for 1 and confirm

**Current behavior:**
cogs are 190

**Expected behavior:**
cogs should be 100

**Cause of the issue:**
_get_posted_cogs_value doesn't take into account 
the credit notes (only the account moves with type 
'out_invoice' are taken into account in the sum)
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/sale_stock/models/account_move.py#L185-L186
So in our case the first invoice and the credit 
note don't cancel out each other.

The same goes for _get_cogs_qty (which returns 
the total cogs past + current), in the past cogs 
it doesn't take into account the quantities of the 
credit note.
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/sale_stock/models/account_move.py#L172-L174
So the quantity of the first invoice and the one of the 
credit note don't cancel out each other.

As a result, the return value from _get_cogs_value() 
for the second invoice is : 
price unit = 100 
returned by _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/account_move_line.py#L68
which returned the standard price because 
the product has an average cost method
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/stock_move.py#L275-L280

cogs_qty = 2 (instead of 1 if credit was taken into account 
as -1 in the sum)
self._get_posted_cogs_value() = 10 (instead of 0 if credit note 
cogs were taken into account  in the sum as -10)
return value = (100 * 2 -10)/1 = 190
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/account_move_line.py#L75
**fix:**
if we take into account the credit note 
the return value will be : 
(100 * 1 - 0)/1 = 100

the mechanism of the already posted cogs value 
is there for cases where we only delivered a part of 
the quantity and then delivered the rest, but in 
the case where we delivered and then returned 
(with credit notes) it shouldn't have an impact. 
Thus the idea to include the credit note so 
that it can cancel out the first invoice

opw-6426111

Forward-Port-Of: odoo/odoo#282893

`qty_available` is by default not computed with sudo, while the `total_value` is. This means that in `_update_standard_price`, the customer configuration can have a negative impact on the standard_price compute.

For example, if a user create a custom rule so that specific users have access to specific warehouses only, compute `total_value / qty_available` can actually mean `global_total_value / partial_qty_available`, which creates an aberrant standard price.

To fix this issue, the _update_standard_price must be done in sudo.

OPW-6243363

---

## Test result without fix
```
2026-06-17 12:24:50,810 47572 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_update_standard_price_with_limited_access_users
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3624, in test_update_standard_price_with_limited_access_users
    self.assertEqual(product.standard_price, 1.0)
AssertionError: 12.11111111111111 != 1.0
 ```

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

Forward-Port-Of: odoo/odoo#271229
Forward-Port-Of: odoo/odoo#270559

**Problem:**
Duplicating a task, creating a task from a task template, or generating the next occurrence of a recurring task scrambles the dependencies between its sub-tasks: each copied sub-task carries the dependencies of a different sub-task instead of its own.

**Steps to reproduce:**
1. Enable Task Dependencies on a project.
2. Create a task with three sub-tasks and chain them: the second depends on the first, the third depends on the second.
3. Duplicate the task, or use "Create from template" if the task is a template.
4. Open the sub-tasks of the new task and look at their dependencies.

**Current behavior:**
The dependencies of the copied sub-tasks are shifted: the chain runs in the reverse order of the original one.

**Expected behavior:**
Each copied sub-task depends on the copy of the sub-task its original depended on, so the new task reproduces the original chain.

**Cause of the issue:**
`_create_task_mapping` builds the original to copy mapping by pairing `original_task.child_ids` with `copied_task.child_ids` positionally, on the assumption stated in its docstring that both recordsets share the same index order. They do not. `project.task._order` ends with `id desc`, so `child_ids` is read newest-first, while the copies are created by iterating the original `child_ids` in that same order. The copies' ids therefore ascend along the original list, and reading them back through `child_ids` returns them in the exact reverse order. `zip` then pairs each original with the copy of the sub-task at the mirrored position, and `_resolve_copied_dependencies` writes every `depend_on_ids` and `dependent_ids` onto the wrong copy. This affects every caller of that method: `copy`, the task template action, and the creation of the next occurrences of a recurring task.

**Fix:**
Sorting the copied children by id restores the correspondence because id order is the order in which the copies were created from the original list, an invariant that holds whatever `_order` does, whereas the previous code silently depended on `_order` producing the same sequence on both sides.

`test_duplicate_project_with_subtask_dependencies` and `test_recurrence_copy_task_dependency` were reading the copies by `child_ids` index too, which the mirrored mapping happened to satisfy, so they passed on a wrong result; they now index them in creation order as well.

opw-6386578

Forward-Port-Of: odoo/odoo#284211
Forward-Port-Of: odoo/odoo#280893

**Steps to reproduce:**
* Install **Accounting** module.
* Go to **Accounting → Bank → Transactions** (bank reconciliation widget).
* Open a transaction with a **positive** amount (e.g. a vendor sending money back).
* Click the three-dot menu on the transaction line and choose **Upload a Refund**.
* Upload any document (XML or PDF).

**Observed behavior:**
* A **Customer Credit Note** (`out_refund`) is created in a **sale** journal instead of a **Vendor Credit Note** (`in_refund`) in a **purchase** journal.
* The wrong document type means the reconciliation fails to link the refund against the correct payable account.

**Cause:**
* In `create_document_from_attachment` (`account_bank_statement.py`), the JS widget sends `type='sale'` in context when the transaction amount is positive (JS: `amount > 0 ? "sale" : "purchase"`).
* The original code mapped `type='sale'` → `default_move_type='out_refund'` (customer credit note) and searched for a `sale` journal — both wrong.
* Uploading from a bank statement is always a **vendor-side** operation: negative amount = vendor bill (`in_invoice`), positive amount = vendor refund (`in_refund`). The `type` context key from JS reflects transaction direction, not the accounting document type.
* Additionally, `in_refund` is a purchase document; Odoo's `_check_journal_move_type` constraint raises a `ValidationError` if a purchase document is created in a non-purchase journal, meaning the old code would crash at the ORM level for the refund path.

**Fix:**
* Map `type='sale'` → `default_move_type='in_refund'` (vendor credit note) instead of `out_refund`.
* Always search for a **purchase** journal regardless of the `type` context value, since both `in_invoice` and `in_refund` are purchase-side documents.

opw-6468779

### Issue before this commit:
Before this commit, users were completely blocked from creating an invoice for a foreign partner (e.g., "Cliente del Exterior") if all exportation journals were archived or unavailable, as the system would immediately trigger a RedirectWarning error.

### Steps to reproduce the issue:
1. Download Accounting and l10n_ar
2. Go to contacts and create a new one with:
	1. Country as United States
	2. VAT number ex. 55000002126
	3. AFIP Responsibility Type as Cliente del Exterior
3. Go to Journals, filter for sales journals and archive:
	1. Electronic Exportation Invoice (FEX)
	2. Expo Sales Journal
4. Go to invoices and create a new one for the client you just created
5. As soon as you insert the client you will receive the error: You are trying to create an invoice for foreign partner but you don't have an exportation journal

### Cause of the issue:
https://github.com/odoo/odoo/blob/014d58e3204d17db6dcba3c8ab7d8ad35003300e/addons/l10n_ar/models/account_move.py#L186-L189 The _onchange_partner_journal method rigidly enforced the use of an exportation journal for foreign AFIP responsibility types (codes 8, 9, and 10). If the query failed to find an active export journal, the code intentionally threw a hard error instead of providing a fallback mechanism.

### Reason to introduce the fix:
This fix is introduced to prevent unnecessary workflow blocks. By catching the missing journal and defaulting the document type to "Invoice B" (code 6), the user can now successfully generate the invoice using a standard domestic sales journal without being forced to configure an exportation journal.

opw-6442501


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

Forward-Port-Of: odoo/odoo#282971

Issues
-----

1. Commercial invoice is not forwarded to the user for the return delivery.
2. US postal codes of format 12345-6789 cause the delivery to be rejected.

-----

Steps to reproduce issue 1
-----
- Set up UPS with return labels
- Create an INTL delivery & confirm

> OUT delivery has a commercial invoice in chatter, but the return doesn't

Cause
-----
The OUT and return call are not made using the same function. The OUT call is made via `ups_rest_send_shipping` which explicitly extracts the commercial invoice from the UPS response

https://github.com/odoo/enterprise/blob/1a7c8ac34348ebc1ebe2da4100bdaec57484056f/delivery_ups_rest/models/delivery_ups.py#L204-L205

We should adapt `ups_rest_get_return_label` to match.

-----

Steps to reproduce issue 2
-----
- Set up UPS
- Create an american customer with a 9 digit zip (eg 20500-0003)
- Create an delivery to the customer & confirm

> Error: Invalid sold to postal code. Valid length is 0 to 9 alphanumeric

Cause
-----
The zip code is transmitted as-is, so we should sanitise it beforehand.

https://github.com/odoo/enterprise/blob/c8c2f13b7fd17e215044fc62774f2b4a378aaf8c/delivery_ups_rest/models/ups_request.py#L368

Doc:
https://github.com/UPS-API/api-documentation/blob/69e8a3cee7f9d3bf80735ae329aed0d8be156f97/Shipping.yaml#L5410-L5420

-----
Ticket:
opw-6422500

Forward-Port-Of: odoo/enterprise#127375

step to reproduce :

1. Create a related field on `sale.order`, for example:

       x_studio_production_stage = tasks_ids.stage_id.name

2. Use this field in a filter:

       [('x_studio_production_stage', 'ilike', 'Dispatch')]

3. Applying the filter raises:

```python
   Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
return service_model.retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 97, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 67, in web_search_read
records = self.search_fetch(domain, specification.keys(), offset=offset, limit=limit, order=order)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1408, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5366, in _search
domain = domain.optimize_full(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 446, in optimize_full
return self._optimize(model, OptimizationLevel.FULL)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 460, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 654, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 609, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 654, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 460, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 654, in _optimize_step
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 609, in _flatten
for child in children:
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 654, in <genexpr>
children = self._flatten(child._optimize(model, level) for child in self.children)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 460, in _optimize
previous, domain = domain, domain._optimize_step(model, next_level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 962, in _optimize_step
domain = self._optimize_field_search_method(model)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1008, in _optimize_field_search_method
computed_domain = field.determine_domain(model, operator, value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1928, in determine_domain
return determine(self.search, records, operator, value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/addons/sale_project/models/sale_order.py", line 76, in _search_tasks_ids
query = self.env['project.task']._search(task_domain)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5355, in _search
domain = Domain(domain)
^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 259, in __new__
raise ValueError(f"Domain() invalid item in domain: {item!r}")
ValueError: Domain() invalid item in domain: ('id', 'any!', [('id', 'any!', <odoo.tools.query.Query object at 0x7aca184f4170>)])
```

Cause:

When searching on the related field, [_search_related()](https://github.com/odoo/odoo/blob/19.0/odoo/orm/fields.py#L768) converts the related path into an `any!` domain:

    ('tasks_ids', 'any!',
        [('stage_id', 'any!', [('name', 'ilike', 'Dispatch')])]
    )

During [Domain.optimize_full()](https://github.com/odoo/odoo/blob/19.0/odoo/orm/domains.py?utm_source=chatgpt.com#L436), [_optimize_field_search_method()](https://github.com/odoo/odoo/blob/19.0/odoo/orm/domains.py?utm_source=chatgpt.com#L1008) calls the field's search method, which invokes `_search_tasks_ids()` with `operator='any!'` and the related domain as `value`.

The existing [_search_tasks_ids()](https://github.com/odoo/odoo/blob/57c7c9938725d392a6f2cd6c89a861d2a8385c44/addons/sale_project/models/sale_order.py#L76) expects a normal search value and therefore generates an invalid nested domain.

Fix :

`_search_tasks_ids()` to directly pass the domain to `project.task._search()` when the operator is `any` or `any!`.

upg - 4584778
opw - 6475804

[here]: https://github.com/odoo/odoo/blob/19.0/odoo/orm/fields.py#L768

[here]: https://github.com/odoo/odoo/blob/19.0/odoo/orm/models.py#L5366

[here]: https://github.com/odoo/odoo/blob/19.0/odoo/orm/domains.py?utm_source=chatgpt.com#L436

[here]: https://github.com/odoo/odoo/blob/57c7c9938725d392a6f2cd6c89a861d2a8385c44/addons/sale_project/models/sale_order.py#L76

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

When paying with an eWallet or gift card in POS, the reward line could end up 0.01 short of the actual card balance if the discount product's tax is configured as tax-excluded through a per-tax override, regardless of the tax's own default configuration. The card is still debited for the full balance, but the order is only discounted by one cent less, so the amount charged to the customer no longer matches the amount consumed from the card.

Steps to reproduce:
-------------------
* Top up an eWallet (or gift card) with a balance of 10.00
* On the eWallet/gift card program's discount product, set an 18% tax whose Tax Computation is overridden to "Excluded" (price_include_override = tax_excluded), independently of the company's default tax configuration
* In POS, add a product to an order and pay (partly) with that eWallet/gift card

> Observation:
Only 9.99 is deducted from the order total, while the backend correctly shows 10 consumed on the wallet/gift card.

Why the fix:
------------
The reward line's price_unit was reconstructed from a one-time backward tax computation, then kept only the tax amount for taxes whose price_include field was true, dropping it for any tax forced excluded. That price_unit was later re-taxed forward using the tax's real (excluded) configuration, and the two roundings don't agree for rates like 18%, losing a cent.

We now force special_mode "total_included" whenever an eWallet/gift card reward line's taxes are computed, not just at creation, so its tax-included total always equals the exact redeemed amount regardless of how the tax is configured, and store price_unit as that target amount directly.

opw-5819389

Forward-Port-Of: odoo/odoo#282609
Forward-Port-Of: odoo/odoo#278568

When having multiple companies selected at the same time, _get_conversion_rate returns:

File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in get
raise ValueError("Expected singleton: %s" % record)

1 - Create a new company with currency EUR.
2 - Create a branch company underneath the main company.
3 - In Accounting, install fiscal localization, e.g. Belgian Companies on the company configuration settings.
4 - Select an account like 600000 Raw Materials, and enable Allow Reconciliation on this account. The exact account isn't important, only that we can make credits / debits to it to be reconciled.
5 - With only the top level company selected, make a debit of 100 USD, e.g. Vendor Bill, set in currency USD to the account 600000.
6 - Now with only the branch level company selected, make a credit of 100EUR, e.g. Customers Invoices, set in currency EUR to the same account with an amount equal to the credit in step 5. (if 1USD == 1EUR, 1-1), so that there is no residual amount, i.e. credit == debit.
7 - Now select both the top level company and the sub branch company in the company context.
8 - In Journal Items, reconcile the unreconciled journal items for the Account 600000.

With this commit we select the first company of the aml instead of every companies on the amls.

opw-6290703

Forward-Port-Of: odoo/enterprise#123774

Modern crawlers now send an `Accept-Language` header (for example, `en-US,en;q=0.9`), whereas historically they did not. When that language differs from the website's default language, `ir.http._match()` issues a 303 redirect from `/page` to `/<lang>/page`. Since crawlers do not retain cookies, unrecognized agents are redirected on every request and never reach the default-language page.

Customers reported that Google Search Console URL Inspection live tests only receive a redirect and that pages remain unindexed. Googlebot itself is not affected because it already matches the existing `bot` token.

`_match()` already skips language redirects for recognized bots by serving the default-language page directly. Extend the `bots` user-agent list with modern crawler identifiers, each verified against vendor documentation:

* `google-inspectiontool`: Search Console URL Inspection / Rich Results Test
* `googleother`: Google generic crawler (`GoogleOther`, `GoogleOther-Image`, `GoogleOther-Video`)
* `meta-external`: `meta-externalagent`, `meta-externalfetcher`, and `meta-externalads`, successors to the already-listed `facebookexternalhit`
* `meta-webindexer`: Meta AI search indexer
* `chatgpt-user`: OpenAI user-request fetcher (currently matched only through the `bot` substring in its info URL, which is fragile)
* `claude-user`: Anthropic user-request fetcher
* `perplexity-user`: Perplexity user-request fetcher

The redirect behavior remains unchanged for human visitors. Localized pages continue to be crawlable through their own URLs (for example, `/fr/page`) via `hreflang` alternates.

As a side effect, `link_tracker` and `mass_mailing_sms` no longer count clicks from these crawlers, and website visitor tracking skips them.

task-6213245

Forward-Port-Of: odoo/odoo#275571

The aim of this commit is to allow customer to make their batch payment
without facing a Traceback.

Context:
odoo/enterprise@35f5341b9b44cc16eaea311295a064189dd802cb introduced bug
during a badly handled forward port.
The method was removed in saas-18.3 in favor of a function. The forward-port
was half handled and now surfaces to Odoo's own production.

Generating a batch payment could generates the following Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal_sepa_ct.py", line 69, in _get_PstlAdr
    return super()._get_PstlAdr(partner_id, payment_method_code)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal.py", line 501, in _get_PstlAdr
    CtrySubDvsn.text = self._sepa_sanitize_communication(partner_address['state'][:35])
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.journal' object has no attribute '_sepa_sanitize_communication'
```

Task-id: None (internal issue)

Forward-Port-Of: odoo/enterprise#129084
Forward-Port-Of: odoo/enterprise#129006

Deleting a draft customer invoice linked to timesheets resets their timesheet_invoice_id so the hours become invoiceable again. This write also marks the timesheets' so_line for recompute, and the re-derivation runs while the lines are no longer protected by the invoice link. When the task or project no longer resolves to a sale order item (e.g. it was unlinked after invoicing), the timesheets lose their sale order item or get reassigned to another one, so the delivered hours silently disappear from the original order line.

Protect so_line during the write and drop the pending recompute: deleting an invoice must only make the hours invoiceable again, not change their allocation.

Steps to reproduce:
- Install Sales and Timesheets
- Create a service product with invoice policy "Based on Timesheets" and "Create a task in a new project"
- Create and confirm a sale order with this product
- Log a timesheet on the generated task
- Create the invoice (keep it in draft)
- Remove the Sales Order Item from the task and from the project settings (or point them to a sale order item of another order)
- Delete the draft invoice
- Open the timesheet: its Sales Order Item is emptied (or replaced by the other order's item, whose delivered quantity now includes the hours sold on the original order), and the original line's delivered quantity is reset

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

Forward-Port-Of: odoo/odoo#281594
Forward-Port-Of: odoo/odoo#279552

## Steps to reproduce:

- Create another warehouse
- Create a product with a variant, like Color, values black and white
- Track the product, add a qty on hand of 50 on the black product
- Go to the sales app, make a quotation of 50 for the black product
- Confirm the quotation
- Go to the PoS, click on the product, check the available qty in the popup
- It is still 50, even though the forecasted is correct at 0

## Why the fix:

Having the actual free qty was added in this commit 682bc82 to be able to check the qty that was really free instead of the available qty. This means that we subtract the reserved_qty from the qty_available to get the free_qty.

The variant popup was forgotten in this commit, so it was still displaying the qty_available. This is why there was a difference in the qty if we press the product normally or if we long press it, because the variant popup was forgotten in said commit.

opw-6382845

Forward-Port-Of: odoo/odoo#283659
Forward-Port-Of: odoo/odoo#280330

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#282963
Forward-Port-Of: odoo/odoo#276905