Steps:
- Install ai
- Open ai chat
- Try to send a message
- Traceback

The AI chat was failing on iOS with a traceback when trying to process
the stream response.

Even though MDN suggests compatibility, Safari (WebKit) versions prior
to 26.4 do not implement the AsyncIterator protocol on ReadableStream.
This makes `for await (const chunk of response.body)` throw a TypeError
as `[Symbol.asyncIterator]` is undefined.

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

This commit replaces the async iteration with a manual reader loop
(`getReader().read()`). This is the low-level primitive supported by
all versions of Safari and ensures the stream is properly consumed and
unlocked even if the connection is interrupted.

Steps to reproduce:
1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4).
2. Send a message.
3. The response triggers a JS error.

```js
Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...')
```

opw-6054307

Forward-Port-Of: odoo/enterprise#113926

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/odoo#261156
Forward-Port-Of: odoo/odoo#257720

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/enterprise#114986
Forward-Port-Of: odoo/enterprise#113047

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
The `_compute_template_id` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96


Solution:
-----------
- Update `_compute_template_id` to ensure only active templates are
  automatically assigned.


opw-5974244





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

Forward-Port-Of: odoo/odoo#260853
Forward-Port-Of: odoo/odoo#251186

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Forward-Port-Of: odoo/enterprise#106464

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#261316
Forward-Port-Of: odoo/odoo#259776

**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
  * Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
  * Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.

**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
  * Case 1 (Demand=10, Done=8):
    * Ordered = 8, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 12, Delivered = 12.

**Expected behavior:**
* Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.

 **Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157

CASE- 1
* When validating with *less quantity* and *no backorder*:
  * In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
  * If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
  * where it take  quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
  * As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.

CASE-2
* When validating with *more quantity* than demanded:
  * `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
  * The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
  * The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
  * In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
  → `qty_ordered += 2`  →  `qty_ordered = 12`  ✗  (surplus added to demand)
  → `quantity += 2`     →  `quantity = 12`      ✓
  * The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.

* After the fix:
  * Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.
    
*  NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
 to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully

Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
    <img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
  </div>

  <p><strong>After:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
    <img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
  </div>
</details>

---

opw-5874759

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

Forward-Port-Of: odoo/odoo#250587

Issue:
----------------------------------------
When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback.

Steps to reproduce:
----------------------------------------
- Have Planning and Time Off installed
- Create a public holiday for another company
- Create an employee with no calendar
- Open Planning and try to add the new employee
- Traceback

Cause:
----------------------------------------
This commit 55ce1e3411d0693807d883ac159039b8141ff6b6 added the new method called `_get_flexible_resource_valid_work_intervals()` which will call `_leave_intervals_batch()` on `self.env['resource.calendar']`. In `_leave_intervals_batch()`, the resource list will contain the fully flexible employee and `self.env['resource.resource']`.

During the handling of the public holiday we created, we loop through the resource list. 
The first one is the flexible employee, but it gets skipped by the `continue` as it has a different company. Because of this the variable `tz` still equals `None`. 
The second resource is `self.env['resource.resource']` which doesn't validate the condition to be skipped. So it reaches the line
```py
tz = tz if tz else timezone((resource or self).tz)
```

But `tz` is still `None` and both `resource` and `self` are empty, so it gives `False` to the timezone constructor, which crashes.

Solution:
----------------------------------------
Add a default value to 'UTC' to handle this specific case.

opw-6107269

Forward-Port-Of: odoo/odoo#259404

In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working.

The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image.

This commit changes the following:

- The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider.
- The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected.
- The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case.

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

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#261316
Forward-Port-Of: odoo/odoo#259776

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#261077
Forward-Port-Of: odoo/odoo#259224

Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`:

* **Redundant updates** were performed on `location_dest_id` in the move lines and the package levels (which internally update all related move lines too), even when the location remained unchanged.
* The main loop inside `_check_entire_pack` was **O(N^2)** time relative to the number of move lines due to internal filtering logic.
* **Cache misses** triggered unnecessary SQL queries when retrieving `move_line_ids` from `package levels`, while they are already cached via the pickings and can be grouped by `package_level`.

---

### Benchmark
Benchmark conducted on a customer database with **400k** `stock_move_line` records within **800** `pickings`, testing performance of the action `StockQuant.action_validate` with different sizes of move lines. Each test was run multiple times and shown is the average mean, all with negligible variance.

| Metric | Before | After | Delta |
| :--- | :--- | :--- | :--- |
| **Benchmark (1k lines)** | 10.5s | 2.2s | -80% |
| **Benchmark (5k lines)** | 121s | 8.5s | -93% |
| **Benchmark (50k lines)** | 887s | 56s | -94% |
| **Benchmark (400k lines)** | timeout | 777s | (within time limit) |

**OPW-6045513**

Forward-Port-Of: odoo/odoo#257829

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#261316
Forward-Port-Of: odoo/odoo#259776

### *Why this commit*: 
---
Ensures Quality Checks and Mass Produce options remain available on the
Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid both the Quality Checks and Mass Produce buttons.
This blocked users from registering Serial Numbers and completing mandatory
quality check steps.

Additionally, for products without BoM operations, clicking Mass Produce 
triggered quality check validation instead leading to errors, preventing the
generation of serial numbers.


### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Mass Produce: Stays visible to allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.


OPW: 5473839

**Description of the issue/feature this PR addresses:**
----------------------------------------------
When replying to messages from the History (Inbox) view, opening the full
composer and discarding it could incorrectly trigger a toast notification
indicating that a message was posted. This behavior is misleading, as no
message is actually sent when the composer is discarded.


**Current behavior before PR:**
----------------------------------------------
- Replying to a message from History opens the full composer
- Discarding the full composer closes the dialog normally
- A “Message posted” toast is shown even though no message was sent
- Notification logic depends on dialog close behavior, leading to incorrect triggers

**Desired behavior after PR is merged:**
----------------------------------------------
- Discarding the full composer does not show any notification
- Notifications are only shown when a message is actually sent

Task-5431682

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

### Issue:
If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags

### Cause:
The `_get_payments_vals` method, `InstrId` is based on the payslip ID
When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers
https://knowledge.xmldation.com/support/iso20022/general_rules/instrid

This commit adds a unique suffix (e.g., -1, -2) to the `InstrId` for each transaction generated from the same payslip to ensure technical uniqueness Nothing change when you only have one account

This is the part of the code that use the payment name:
https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299

### Steps to reproduce:
- Install `hr_payroll_account_iso20022` with demo data
- On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number`
- Open the Employee page for Abigail Peterson
- In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any)
- Click on Salary Allocation and Save (You'll have a 50/50 ratio)
- Create a new Pay Run (for Abigail Peterson)
- Open the last PaySlip and Validate
- Create Payment Report (Export Format: SEPA)
- Download the Payment Report and check the <InstrId> tags

opw-6069670

Forward-Port-Of: odoo/enterprise#114821
Forward-Port-Of: odoo/enterprise#113113

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

When we add a byproduct followed by SN directly in the MO it will not have the its location as production.

Steps to reproduce:
-------------------
* Create product tracked by Serial number
* Create a Manufacturing order
* Add the Product tracked by serial number on the MO as byproduct
* Confirm the MO
* Go to shop floor
* Add the by-product quantity and create a new serial number.
* Close production and go back to the MO in manufacturing
* Open stock moves -> the by-product does not have "production" for origin

Observation:
-------------
When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM.

When adding the byproduct in shopfloor, it will create the quant:
https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171
Additionaly when creating the quant it will decide the source location depending if the product its a byproduct:
https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192
The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids
https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110

#### Additional notes:

The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false


opw-5974582

Problem:
Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small.

Solution:
Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold.

Before:
<img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" />

After:
<img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" />

Steps to reproduce:
- Change languange (French to have a long placeholder).
- Settings > Customer Invoices > Default Terms & Conditions.
- Check "Add a Note".
- Resize the screen to smaller size.
- Observe the power buttons overlap with the translate button.

task-6117734

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

**Steps to produce:**
- Install `sale_management` without demo data.
- In settings > Under Taxes > Set `Tax Prices` as `Tax Included`.
- Create a product with a sales price of 10.
- Create a quotation with this product.
- Confirm the line amount shows 10 (tax included).
- Click on preview.

**Observation:**
- In the preview, the product line amount is shown as tax excluded.

**Root cause:**
- At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`.
- This logic is not applied in the portal preview and PDF report.

**Solution:**
- Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`.

[1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663

Before:
---
<img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" />

After:
---
<img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" />

opw-6089473
---

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

Behavior before:
When running the CodaBox transaction fetch (via cron or manual trigger), the process would crash with an "Expected singleton: account.journal(id1, id2)" error if multiple journals were found sharing the same sanitized bank account number. This made the automated import flow unusable for users with duplicate numbered bank accounts.

Behavior after:
The CodaBox import flow completes successfully even if multiple journals share the same account number. The system now correctly identifies and binds to a single journal record, preventing the crash and allowing the statement creation to proceed.

Root Cause:
In _find_additional_data(), the search for a journal based on the sanitized_account_number lacked a record limit. If a database contained multiple journals for the same IBAN, the search returned a recordset containing multiple IDs. When the flow subsequently attempted to call instance methods or access fields on this recordset, the ORM triggered a ValueError because it expected a singleton.

Fix:
Added limit=1 to the search in _find_additional_data(). This ensures that even if the criteria match multiple journals, only a single record is returned and used for the statement import, maintaining consistency with Odoo's singleton requirements for journal-based operations.

opw-5462037