### Steps to Reproduce:
1. Create a sign request and have 3 total signers (User, Customer, Employee)
2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee
But make the User and Employee the same contact
3. Send and sign the request > Notice that (1) is able to sign for (3) immediately after, (2) has not signed yet.

### Description of the issue/feature this PR addresses: 
**Issue:** The signing order is ignored when the same user has to sign multiple times on a document, even if it is configured for a different person to sign in between. This happens because all signature request items are initialized in the 'sent' state upon creation, rather than strictly advancing based on the order. As a result, the system prematurely allows users to sign out of order and prompts them with their next turn too early.

**Solution:** To resolve this,  the controller was updated to include an `is_mail_sent = True` domain filter. This ensures that the UI's post-sign popup only displays documents where it is explicitly the user's active turn, rather than prompting a premature sign.

### Current behavior before PR: 
Users are able to sign prematurely, and the system will disregard the configured signing order.

### Desired behavior after PR: 
Users will only be prompted and able to sign a document when it is explicitly their turn, per the `mail_sent_order`. This way, documents are signed in order.

opw-6417327

Forward-Port-Of: odoo/enterprise#128487
Forward-Port-Of: odoo/enterprise#125573

Issue:
UAE companies cannot create their salaries bank account directly from Payroll Settings. The bank account cannot be saved, leaving payroll configuration incomplete and preventing the UAE WPS process from being completed.

Steps to reproduce:
* Configure an Emirati company with the UAE Payroll localization.
* Open Payroll > Configuration > Settings.
* Create a new Salaries Bank Account from the settings field.
* Fill in the bank details and try to save the account.

Cause:
Since saas-19.2, the bank account form hides the required account holder and expects the opening field to provide it through `default_partner_id`.
The UAE salaries bank account setting only restricts selectable accounts through its domain and does not provide that creation default. Newly created accounts therefore have no owner and cannot be saved.

Domains only filter selectable records and do not initialize fields on new records. Since the shared bank account form hides the required partner, accounts created from Payroll Settings have no owner and cannot be saved.

Solution:
We need to provide the current company partner as the account creation default while retaining the existing selection domain. This preserves the company and country restrictions and guarantees that newly created salaries accounts satisfy the required ownership invariant.

opw-6441848

Steps to Reproduce :
1. Go to Website → Edit Mode
2. Add a snippet with button
3. Click on button and change its type to : " Custom"
4. Apply the gradient type color in fill color option
5. Apply any color in text color option
6. You will notice that the gradient type color in fill color option is
removed.

Problem:
Since [this commit][1] new button style options have been added to the
sidebar. If one changes the style of a button to custom, changes the
background to gradient, and tries to change the text color, the
background gradient is removed.

Cause:
Whenever a gradient is added either to text or as a background, it is
applied as a background image. In the case of a text gradient, an
additional class, `text-gradient`, is applied for correct styling. Once
a change to either color or background/fill is applied that is not a
gradient color change, the background image of the element would be
reset to nothing. This is the result of [this line][2] from a [previous
commit][3]. In the case of a button, this meant changing the font
color would reset the background. That is not the desired outcome.
The flaw was only discovered once new options were added to change
non-text/font elements' backgrounds to gradient.

Solution:
An additional check has been added to see if the element being edited
is text. If so, and it's a gradient style being changed, we remove the
background image. Otherwise it is kept so that the button case from
above is resolved.

[1]: https://github.com/odoo/odoo/commit/2bf1db001b195480b963b338583c170aa1c009a3
[2]: https://github.com/odoo/odoo/blob/8e0845712f462ecfafd2176406dcbafc869a5564/addons/html_editor/static/src/main/font/color_plugin.js#L575
[3]: https://github.com/odoo/odoo/commit/8e0845712f462ecfafd2176406dcbafc869a5564

task-6247134

## Description of the issue/feature this PR addresses:

Two related Nilvera e-invoice issues affecting Turkish companies:
- The "Fetch Nilvera PDF" button appeared for every company, not just Turkish ones.
- Sending/fetching e-invoices (or fetching the PDF) as a non-admin Invoicing user raised an
  AccessError, because the company's Nilvera API key field is restricted to System/Settings users
  and several call sites read it without `.sudo()`.

## Current behavior before PR:

- The PDF-fetch button shows on both the list view and form view of `account.move` regardless of
  the company's country.
- An Invoicing-only user (no System/Settings access) gets an AccessError when sending/fetching
  e-invoices or fetching the PDF, because `_get_nilvera_client` reads
  `company.l10n_tr_nilvera_api_key` without `.sudo()`.

## Desired behavior after PR is merged:

- Both buttons are only visible for Turkish companies (the list-view button has no bound record, so
  its gate is driven by a new `l10n_tr` session_info/JS context injection instead of a direct field
  reference).
- Invoicing users can send/fetch e-invoices and fetch the PDF without hitting an AccessError.

## Things to add on forward-port

The `.sudo()` fix lives inside `_get_nilvera_client` itself (`l10n_tr_nilvera/lib/nilvera_client.py`),
so every caller that goes through it is already fixed automatically once this diff forward-ports.
Only call sites that read `company.l10n_tr_nilvera_api_key` **directly**, bypassing
`_get_nilvera_client`, still need their own `.sudo()`:

### 19.4
- [ ] Fix e-Dispatch/e-Receipt fetch gate-check access error (direct read of the API-key field,
      sudo it the same way as `_l10n_tr_nilvera_company_get_documents` in this PR)

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

Forward-Port-Of: odoo/odoo#284003
Forward-Port-Of: odoo/odoo#274312

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

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

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

The FSM tour needs to wait until the worksheet view is fully loaded before filling it. Otherwise, the tour may continue too early and the worksheet is not saved properly, causing the worksheet section to be missing when previewing the task report.

A synchronization step was added for this purpose by waiting for `x_comments`, the default HTML field of a worksheet. 
(Related: https://github.com/odoo/enterprise/pull/116918)
However, the demo Device Installation and Maintenance worksheet replaces the generated form view and does not render `x_comments`. It renders the `x_description` text field instead, causing the tour to time out when demo data is installed.

To fix the discrepancy, we need to wait for the editable field of either worksheet variant directly. When the default worksheet is used, fill the `x_comments` HTML editor. When the demo worksheet is used, fill the `x_description` textarea instead.

This keeps the synchronization needed to avoid the worksheet loading race while allowing the tour to run with and without demo data.


[error-939242](https://runbot.odoo.com/odoo/error/939242)

Forward-Port-Of: odoo/enterprise#128245

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

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

The POS Avatax tour sporadically failed after returning from the payment screen. The race was reproduced locally by delaying the mocked Avatax response in mocked_request().

There's three somewhat related fixes.

Firstly, get_order_tax_details() calls sync_from_ui(), which emits a SYNCHRONISATION notification. Unlike the normal POS sync path, the Avatax RPC did not pass the device context. The browser therefore treated its own notification as coming from another device and started an independent reload of open orders.

That reload could replace the current order state after the tour returned to the product screen, causing the selected order line to disappear.

We now pass the normal sync context so the browser can properly ignore its own notification.

Secondly, we'll keep the complete sync_from_ui() response and replace its order, line, tax, and tax group data after the AvaTax calculation. We then simplify the processing client-side by moving towards the established pattern in the POS: missingRecursive() to load any other referenced records, and then pass that through loadConnectedData().

Lastly, clickPayButton() only waits for the payment screen element to be displayed. The AvaTax request starts from the screen's onMounted() callback, leaving a short window where the screen and its buttons exist but the request and UI blocker have not started yet. The next tour step can probably run during that window. To make sure this can't happen we explicitly waitRequest(). This first waits for requests to appear and then waits for them to complete.

runbot-error-944281

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

When a user tries to create an invoice for a PoS order, a traceback occurs.

Steps to reproduce the error:
- Install ``point_of_sale`` and ``sale_stock_product_expiry`` with demo data
- Go to Settings > Enable Display Lots & Serial Numbers on Invoices
- Create a product > Tracking: By lots >
  Enable Expiration Date in Inventory tab > Save
- Create a lot number and add on hand quantity for the product
- Add the product into the Furniture Shops PoS Product Categories
- Open Register of Furniture Shop > Add the product > set customer >
  Payment > Uncheck invoice > Pay
- Go to Point of Sale > Orders > Orders > Open that Order > Click Invoice

Traceback:
```py
AttributeError: 'pos.pack.operation.lot' object has no attribute 'expiration_date'
```

https://github.com/odoo/odoo/blob/039c5139119c9f59bcd999afebf61145be1f5b27/addons/point_of_sale/models/account_move.py#L58
When the Invoice button is clicked, ``_extract_extra_invoiced_lot_values`` method is called.
But here, ``lot`` is a ``pos.pack.operation.lot`` record. which does not contain ``expiration_date`` field.

https://github.com/odoo/odoo/blob/039c5139119c9f59bcd999afebf61145be1f5b27/addons/sale_stock_product_expiry/models/account_move.py#L9-L12

The method ``_extract_extra_invoiced_lot_values`` is designed to work with ``stock.lot`` record.

Solution:
Ensure ``_extract_extra_invoiced_lot_values`` is called with the corresponding ``stock.lot`` record instead of ``pos.pack.operation.lot``.

sentry-7375746210

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