Reason:
- Moroccan companies usually use cash basis accounting. And the cash basis
  entries are only made when the invoices are reconciled with the bank
  transactions. However, in Morocco, there is no Moroccan bank available for
  bank synchronization.

Before this commit:
- We are not assigning the outstanding accounts on the bank journals by default.
- Which is causing the issues when the user creates a payment without an entry
  and without having any bank transactions to reconcile it with. Therefore, the
  tax report won't show the moves and taxes that occurred in the period.

After this commit:
- Introduced a method for updating the accounts on the payment method lines of
  the bank journal in the account module, as we need the same functionalities in
  l10n_in as well.
- For Moroccan localization, from now on, we are setting the outstanding accounts
  automatically on the bank journals.
- The payment accounts are applied by default during CoA loading and whenever
  payment method lines are recomputed, ensuring accounts remain consistent.

Task-6041119

Forward-Port-Of: odoo/odoo#254642

The withholding tax exemption for the employer intervention in home-work transportation costs (500 EUR/year - 41.70 EUR/month for income year 2026) was estimated from contract fields (car_atn, private_car_employee_kilometer) instead of the amounts actually taxed on the payslip. As a consequence:

- The fuel card for daily commute was fully taxed: the employee never received the exemption they are legally entitled to.
- The private car reimbursement was paid net, never added to the taxable base, yet it still granted the exemption on the yearly taxable: a double benefit.
- A bike allowance paid above the exempt rate per km (0.37 EUR/km in 2026) was never taxed.

The exemption is now computed from a new TRANSPORTATION_BASE salary rule category accumulating the taxable transportation amounts of the month:

- ATN.CAR and FUEL_CARD_COMMUTE (already taxed) are tagged with the category.
- New hidden rules CAR.PRIV.TAX and CYCLE.TAX fictively add the private car reimbursement and the above-rate bike excess to the withholding base, after ONSS and before the gross totals, while the reimbursements themselves remain paid net.
- TRANSPORT_TAX_DED becomes -min(yearly taxable, yearly threshold, 12 x monthly transportation base), including the transport lines of already validated payslips of the same month so that non-periodic (regularisation) payslips preserve the monthly totals. The termination fees variant uses the category without x12, its base being annual.

The obsolete helper _get_be_withholding_taxes_transport_deduction is removed, and the affected payslip validation expectations are updated to the corrected amounts.

task-6388103

In Gantt views, for a given focus date, the appropriate time interval is
displayed by finding its start and end date, based on the scale.

For example, if I focus on 18 may 2026 with a month scale, then the
whole month of may is displayed.

The behaviour was as expected in standard code, because all
localisations agree on the beginning of the available scales (day,
month, year).

In custom code, however, some customer requires to see the gantt charts
with a weekly scale. The differences in start of the week based on the
localisations and the inconsistencies of use of localStartOf breaks the
view.

For example, if the localization has the start of the week on a sunday,
and a task on the first column starts on a sunday as well, it will get
assigned to column before (because it considers sunday as the last day
of the previous week). The column before the first column does not
exist, so one empty column is created to put the task in it.

This commit fixes these inconsistencies so that GanttRenderer behaves as
expected with weekly scales, without changing the standard behaviour.

Tests are written to check both that the task is assigned to the proper
localized week (starting on Sunday) and column (1, not 0).

Forward-Port-Of: odoo/enterprise#118625

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

**Steps to reproduce:**
1. Open a Sale Order report in Studio
2. Delete the Taxes column
3. Save
4. Create a sale order with at least one section line and products that have taxes
5. Print the sale order PDF

**Issue:**
- A blank column is rendered in the PDF report on section (and combo) rows whenever a column such as Taxes or Discount is removed via Studio.

**Why this happens:**
- The section row's `colspan` and the combo row's `colspan` were computed using `3 + (1 if display_discount else 0) + (1 if display_taxes else 0)`.
- `display_taxes` and `display_discount` are derived from order data (i.e. whether any line has taxes/discounts), not from which columns are actually rendered in the table.
- When Studio removes a column it deletes the `<th>` and matching `<td>` elements via XPath, but these Python variables remain `True`. As a result, section/combo rows still accounted for the removed column in their `colspan`, producing one extra cell and a visible blank column.

**Fix:**
- Introduce a `colspan_count` variable  which is incremented  inside each `<th>` body
- Use that counter for `td_section_name` and `td_combo_name` instead of the previous formula.
- Because the increment occurs inside the `<th>` element, it is skipped whenever the element is not rendered, whether because `display_taxes`/`display_discount` is `False` or because Studio's XPath removed the element entirely.

opw-6433679

Forward-Port-Of: odoo/odoo#283657
Forward-Port-Of: odoo/odoo#280719

`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

Bug
===
When notifying by email a tracking change, the arrow and parentheses are not rendered in the email body.

Technical and Constraints
=========================
The class `o_track` is only set in the web client template (`mail.Message`).

There's no class in the body of the email that is sent. It can be rendered with "notification templates" that we cannot change either (and they just do `t-out="message.body"`, so the body field of the mail message has to be properly rendered).

We also need existing mail messages to be rendered correctly, and so we need a way to differentiate mail messages created before the fix from those created after it, to know when to disable the arrow and parentheses.

Alternatives
============
We have tough about many solutions, this one is the best we found based on the constraints we have

1. Add a class in 19.3, use that class to not remove the arrow on previous mail message. That solution required a migration script that will change all tracking messages. Because the initial migration of the tracking was really slow, we wanted to avoid that.
2. Add a class, and keep it forever. But that solution makes the body of the mail messages bigger, which defeat one of the purpose of the initial refactoring
3. Change the outgoing email without changing the body of the mail message. That solution was really not reliable (regex change to add the arrow, and we have no clean way to target the tracking rows)
4. During the migration create a system parameter with the date, and compare with the create_date of the mail message to know if we should add the arrows or not (but we will need to keep that system parameter forever, and the code to support both to)

Task-6424104

## Context:
When all references to stock functionality were extracted from point_of_sale in this PR: #241368, we decoupled the query ordering logic from the rest of our product.template data-fetching code: https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/point_of_sale/models/product_template.py#L190

This allowed us to completely override (not extend) the ordering of the loaded products in our new pos_stock module:
https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/pos_stock/models/product_template.py#L42-L65

Notice the difference in point_of_sale:
https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/point_of_sale/models/product_template.py#L403-L416

This was causing problems with our existing test for this feature in point_of_sale because we were explicitly examining the ordering of the products; obviously this ordering would be different when pos_stock is installed alongside point_of_sale.

Thus, we must decouple our original test for this feature so that ordering can be examined independently in each module's tests.

## Now:
We have one test in point_of_sale that just makes sure our limited products loading feature actually caps the number of products loaded. This test will work correctly whether or not pos_stock is installed.

In addition, we have one more test in point_of_sale and pos_stock that explicitly examines the ordering of the products in these limiting conditions when both modules are installed. The point_of_sale test will be skipped when pos_stock is installed because the latter module defines conflicting ordering.

runbot-243064

Steps to reproduce:
- Insert two tables in the editor.
- Merge cells in the first table.
- Select the merged cell in the first table.
- Open the table menu for the second table.
- Observe that the "Unmerge Cells" option is available even though the second table has no merged cells.
- Click "Unmerge Cells".
- The merged cell in the first table is unexpectedly unmerged.

Description of the issue:
- The "Unmerge Cells" option is shown for the second table when a merged cell from the first table is selected.
- Clicking the option unmerges the selected cell from the first table.

Cause:
- In `getSelectedCellsMergeInfo`, `canUnmerge` was determined using `td.rowSpan > 1 || td.colSpan > 1` without checking whether the cell belonged to the target table.

Solution:
- Verify that the selected cells (`td`, `firstCell`, and `lastCell`) belong to the `targetTable` before allowing merge or unmerge operations.
- Prevent merge and unmerge operations from being applied to cells in a different table.

task-6475293

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

**Steps to reproduce:**

- Create a contact with a phone number that has 9 characters
- Setup an UPS carrier, a configuration that works is UPS Saver as Service Type and UPS Package/customer supplied as a package type
- Create a quotation, put the created contact as a client
- Try adding a shipping and getting the rates
- An User Error appears, the phone number is too short

**Why the fix:**

Before this commit, any phone number that was less than 10 characters would raise an User Error, but some countries, such as Luxembourg, use phone numbers that are nine characters long or even less.

If we check the official UPS documentation (https://developer.ups.com/tag/Shipping?loc=en_EN#operation/Shipment), we can see in the Ship_to/Phone section, that the phone number should be a number between 1 and 15, not saying it should be 10 characters or more.
<img width="495" height="473" alt="image" src="https://github.com/user-attachments/assets/fed82987-ffb8-4b84-b282-6c3d3b4f304e" />


After this commit, we adapt the way we prevent the user from inputing phone numbers to fit the official UPS documentation.

opw-6307577

Forward-Port-Of: odoo/enterprise#128632
Forward-Port-Of: odoo/enterprise#122831

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

Steps to reproduce:
----------------------------------
1. Install the `timesheet_grid` module.
2. Create a project and add any timesheet to it.
3. Archive the project.
5. From the systray timer, click on the Project field.

Observation:
----------------------------------
The archived project is visible in the dropdown.

Issue:
----------------------------------
In Odoo, standard search views and `name_search` calls on `project.project` automatically respect `active_test=True`. When you open the timer, the frontend passes `{'timesheet_timer_search': True}` in the context to `name_search` with an empty query string. `name_search` overrides standard searching to retrieve recently used projects first by querying `account.analytic.line` via `_get_recently_used_records ('project_id', ...)`. `account.analytic.line` stores past timesheet logs. Even after a project is archived, historical timesheet records for that project still exist in `account.analytic.line`. Because `_get_recently_used_records` runs a `_read_group` query on `account.analytic.line` (which has no active field of its own), it fetched the `project_id` from historical timesheet entries without checking if the referenced project was active.

Solution:
----------------------------------
In `name_search`, explicitly append `[('active', '=', True)]` to the `project_domain` used when querying `_get_recently_used_records`. Standard form/list views using `_domain_project_id` already benefit from Odoo's default ORM `active_test=True` mechanism during standard `project.project` searches.

Note:
----------------------------------
Another solution was to add `active = true` in `getTimesheetTimerFieldInfo` https://github.com/odoo/enterprise/blob/22eb84cdc94ba334d42bad32fb491d35c8147c94/timesheet_grid/static/src/services/static_timesheet_timer_service.js#L322-L328

Fixing it in Python ensures that any call passing `timesheet_timer_search` in context (e.g. mobile widgets, custom RPCs, or python wizards) will benefit from the fix, rather than only patching a single OWL JS service.

opw-6445528

Forward-Port-Of: odoo/enterprise#127374

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