Accessing an order on the website without connecting (only with the access token) doesn't allow the user to return the order (nothing happens when click on the "Return" button)

Steps to reproduce:
1. Install Sales and Inventory
2. Go to Settings > Inventory > Operations and enable "Allow Spontaneous Returns"
3. Go to Sales and create a new quotation for customer "Acme Corporation" with product "Acoustic Bloc Screens" and confirm it
4. Go to the related delivery, set the quantity to 1 and validate it
5. Go back to the sale order and click the "Preview" smart button
6. Copy the url (/my/orders/<id>?access_token=...) and open it in an incognito window
7. Click the return button on the order page
8. Nothing happens

Issue:
The route to `my_order_return_data` requires the user to be logged in

Solution:
Make the routes `my_order_return_data` and `order_return_label` public
For 19.4: access `return.reason` records with sudo (should be removed in master)
For master: add read right on `return.reason` for public users

opw-6487767

Issue:
Internal users assigned to a task in an "Invited internal users" project can read the task but may receive an access error when opening it. Adding them as project followers avoids the error but also exposes the project's other tasks.

Steps to reproduce:
- Set a project's visibility to "Invited internal users".
- Assign an internal Project user to one of its tasks.
- Keep the user out of the project's followers.
- Open the assigned task through its access link.

Cause:
The task form loads feature flags whose computations read their values from the parent project. These computations run as the assignee, who can read the assigned task but not the invited-only project, causing a project access error.

Additionally, the project many2one widget declares `is_template` as a related field. This makes web_read request `project_id.is_template` even though the widget uses the task's own `is_template` value.

https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L277
https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L295
https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/static/src/components/project_many2one_field/project_many2one_field.js#L36-L39

Solution:
We need to compute the inherited task feature flags with elevated access so their values do not depend on the assignee's access to the parent project.

declare `is_template` as a dependency of the current task instead of a related field of `project_id`. The task form therefore no longer reads the inaccessible project while its access restrictions remain intact.

opw-6475880

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

### Issue before this commit:
When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Currencies and activate another currency like EUR
3. Go to Journals and create a new one with bank type and curency EUR
4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal
5. Go to test bank journal and create a new bank matching
6. After the line is created click the 3 dots and go to Manage Models
7. See that the new model Tester created does not appear

### Cause of the issue:
Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. 
https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100

### Reason to introduce the fix:
The filter is not working correctly. In this case it's better to change 
it to a domain instead of a default filter.

opw-6481970

Forward-Port-Of: odoo/enterprise#129992

### Problem

When an AI agent includes a document source whose underlying `ir.attachment`
has `res_field` set (e.g., an invoice PDF generated from a Sale Order),
triggering **Update With AI** from **Website → Site → Optimize SEO**
raises a `KeyError` in `_build_rag_context`.

### Steps to Reproduce

1. Open the **AI** app.
2. Configure the **Odoo Agent**.
3. Add a source → **Add From Documents**.
4. Select a document whose underlying `ir.attachment` has `res_field` set
   (e.g., an invoice PDF generated from a Sale Order).
5. Go to **Website → Site → Optimize SEO**.
6. Click **Update With AI**.
7. Observe the following error:

```
KeyError: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
```

[Video](https://drive.google.com/file/d/1AAg0AvC3TRQzMLhI9hWFuSarOTHzQE-b/view?usp=sharing)

### Root Cause

In `ai/models/ai_agent.py`, `_build_rag_context()` retrieves the
`ai.agent.source` records corresponding to the embeddings by searching on the
attachment checksum:

```python
agent_sources = self.env["ai.agent.source"].search([
    ("attachment_id.checksum", "in", embeddings_attachment_checksums),
    ("agent_id", "=", self.id),
])
```

This domain traverses `attachment_id.checksum`, which internally calls
`ir.attachment._search()`.

As part of the standard attachment search behavior,
`ir.attachment._search()` automatically injects a
`('res_field', '=', False)` filter unless:

- `skip_res_field_check=True` is set in the context,
- the domain explicitly references `id` or `res_field`, or
- `bypass_access` is enabled.

```python
domain = Domain(domain)
if (
    not self.env.context.get("skip_res_field_check")
    and not any(d.field_expr in ("id", "res_field") for d in domain.iter_conditions())
    and not bypass_access
):
    disable_binary_fields_attachments = True
    domain &= Domain("res_field", "=", False)
```

[Reference](https://github.com/odoo/odoo/blob/19.0/odoo/addons/base/models/ir_attachment.py#L630)

Because of this implicit filter, attachments with `res_field` set are excluded
from the search. Consequently, `agent_sources` does not contain all the sources
corresponding to the retrieved embeddings.

Later, `_build_rag_context()` builds a checksum-to-source mapping:

```python
source_map = {
    source.attachment_id.checksum: source
    for source in agent_sources
}

for embedding in similar_embeddings:
    checksum = embedding.attachment_id.checksum
    agent_source = source_map[checksum]
```

Since `source_map` is built from the incomplete `agent_sources` recordset, it is
missing entries for attachments filtered by `ir.attachment._search()`.
However, `similar_embeddings` still contains embeddings for those attachments.

As a result, the lookup:

```python
agent_source = source_map[checksum]
```

raises a `KeyError`.

### Solution

Bypass the implicit `res_field` filter when searching `ai.agent.source`:

```python
agent_sources = (
    self.env["ai.agent.source"]
    .with_context(skip_res_field_check=True)
    .search([
        ("attachment_id.checksum", "in", embeddings_attachment_checksums),
        ("agent_id", "=", self.id),
    ])
)
```

This ensures that all `ai.agent.source` records matching the requested
attachment checksums are returned, including those referencing attachments with
`res_field` set. As a result, `source_map` contains all expected entries and
`_build_rag_context()` no longer raises a `KeyError`.

opw-6379816

Forward-Port-Of: odoo/enterprise#127725
Forward-Port-Of: odoo/enterprise#125780

## Steps to Reproduce:
- Install the hr_work_entry module.
- Create an employee.
- Payroll tab > create a contract by setting only the start date (leave the end date empty).
- From the contract version timeline (navigation bar), click the "+" button and create a new version.
- Open the cog menu (gear icon) and click 'Export Time Entries'.

## Error:
`ValueError - Expected singleton: hr.version(257, 258)`

## Cause:
Method `_get_contract_versions()` returns multiple versions for the given period.
for example:
`contract_dict = {datetime.date(2026, 8, 1): hr.version(1, 2)}`
The code assumes each value is a singleton and builds the recordset using `c.id`,
`[c.id for c in contract_dict.values()]`
Since `c` contains multiple records, accessing the ID will raise an error.

## Fix:
Instead of accessing `id`, it will access `ids`, and it returns the list of all records (`[1, 2]`). 
`chain.from_iterable()` flattens this list into one iterable sequence `(1, 2, ...)`, and 
then it will convert into a list and be passed to `browse()` to fetch the corresponding recordset.

sentry-7623869169

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#281420

**Steps to reproduce:**
1. Install Sales, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Create a sale order with a name that doesn't include any characters (numbers only), confirm, click preview and attempt to make a payment using SEPA

**Issue:**
`The statement descriptor must contain at least one Latin character.`

**Cause:**
The previous fix (4fde0232b821c9a1d46d589ff14495f4e19029f4) passed the order reference directly, assuming it will contain characters.

The intended behavior is to actually have the company name used in the statement descriptor field: https://support.stripe.com/questions/what-is-a-statement-descriptor-and-how-do-i-update-it
This was the existing behavior before the fix, so will revert back to it.

opw-6497127

Forward-Port-Of: odoo/odoo#286620
Forward-Port-Of: odoo/odoo#286287

# How to reproduce
- Set the current employee's schedule to one with :
    - Schedule Type : Flexible
    - Total : a different amount than "Full Time Equivalent"
- Go to My Timesheets
- Add a new line with some Time Spent > 0
- Hover the bottom right cell of the grid (this is the total overtime for the week)

# The issue
The computation of the overtime for the week is based on "Full Time Equivalent" instead of "Total". This is inconsistent with the Planning app and the All Timesheets view.

# Cause
This [PR] introduced the usage of `full_time_required_hours` to compute the total overtime. This field was used because `hours_per_week` ("Total") was thought to be computed using `resource.calendar.attendance`. However, that is not the case when the schedule is flexible : https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L220 https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L163-L166

[PR]: https://github.com/odoo/enterprise/pull/81057

opw-6303520

Forward-Port-Of: odoo/enterprise#130087
Forward-Port-Of: odoo/enterprise#125510

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `quality_control` module
- Create a picking order with a product
- From the gear menu, create an on-demand Quality Check
- Set the check to *Control per Quantity* and back to the picking
- Set the done quantity to 10
- Open the Quality Check wizard
- Try to fail 3 units

Issue:
------
Validating the partial failure raises a `ValidationError`:

    - Missing required value for the field 'Team' (team_id)

The quality check split is not performed and the picking cannot be processed.

Cause:
--------
Quality checks created on-demand from the picking (via the gear menu) have 
no associated `quality.point` or `stock.move.line` — only 
`picking_id` is set at creation time.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457

In `_move_to_failure_location()`, the `move_line` branch assumes 
`check.move_line_id` is populated. Since it is empty for on-demand 
checks, the split logic operates on an empty recordset.

The new quality check for the split is then created via:

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493

At this point both `failed_move_line` (a copy of the empty move line) and
 `check.point_id` are empty. `_get_check_values(False)` cannot derive 
fields normally sourced from the quality point (`team_id`, `company_id`,
 `measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation.

Fix:
----
- If the quality check is not linked to a move line, find the matching move line
 from the picking before splitting the failed quantity.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97

- `_get_check_values()` normally takes values from a Quality Point. 
Since on-demand quality checks do not have one, fill the missing 
values (`team_id`,  `measure_on`) from the original quality check instead.

This allows manually created quantity-based quality checks to be 
split correctly after a partial failure.

---

opw-6428749

Forward-Port-Of: odoo/enterprise#130275
Forward-Port-Of: odoo/enterprise#126505

**Step to reproduce :**

1. Create Product A and enable lot tracking for it.
2. Create a Kit product and add Product A as one of its components.
3. Go to PoS and create orders using:
  - Product A
  - The Kit product
  - A combination of Product A and the Kit product
4. Create three different orders with these combinations.
5. Try to close the PoS session.

**Issue :**

An error occurs when attempting to close the PoS session.

The issue is in the pos_mrp module, specifically in the _get_lot_line_qty method. When accessing the following line:

`lines_data[move.bom_line_id.bom_id.product_tmpl_id.product_variant_id.id]['order_lines'].qty`

we expect order_lines to contain a single record. However, in this scenario, multiple order lines can be returned for the same product. As a result, accessing .qty directly on order_lines raises a singleton error.

**Solution :**

With this fix, we first retrieve the quantity from each order line and thensum the quantities together.

This ensures that multiple matching order lines are handled correctly and prevents the singleton error when closing the PoS session.

opw-6442765

Forward-Port-Of: odoo/odoo#285612
Forward-Port-Of: odoo/odoo#281622