**Problem:**
When sending an Email to multiple Applicants when one Applicant does not have a `partner_id` set, all Applicants set to receive the email will copy the `email_from` of the Applicant without a `partner_id`.

**Cause:**
When sending an Email to an Applicant record that does not have a `partner_id` set on it, a new Contact is created to be set to the Applicant. When this Contact is created, its `applicant_ids` value defaults to the Applicants in the context. This causes all Applicants in the current context (i.e. the recipients of the Email) to be set on the Contact, also causing that Contact to be set as the `partner_id` of all the Applicants, rather than just the one missing a `partner_id`. This then causes the `email_from` of the Contact to be set on all the Applicants.
https://github.com/odoo/odoo/blob/ccd167e23ea80545e4f09e2302c1b2489e8c42d8/addons/hr_recruitment/wizard/applicant_send_mail.py#L40-L42 https://github.com/odoo/odoo/blob/ccd167e23ea80545e4f09e2302c1b2489e8c42d8/odoo/orm/models.py#L1292-L1293

**Purpose:**
Modify the `create` call used to create the new Contact to define `applicant_ids` as only the Applicant that the Contact is being created for.

**Steps to Reproduce in Runbot:**
1. Delete the Contact corresponding to the `partner_id` of any given Applicant.
2. Select multiple Applicants, including the one whose `partner_id` was deleted, then send an email to them using the Actions menu.

opw-6383263

In this PR, https://github.com/odoo/odoo/pull/186250, the `product_uom` field was renamed to `product_uom_id`. However, in the `delivery` module, `product_uom_id` is dropped from the values when the delivery line is created. 
This causes `product_uom_id` to be recomputed.

This commit reintroduces `product_uom_id` in the values to prevent the field from being recomputed.

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

For a strange reason, when a module inherits from `sale.order.line` and adds some computed fields with `precompute=True`. `price_unit`, `price_subtotal`, and `price_total` are computed incorrectly.

I have attached a module to demonstrate the issue.

https://github.com/user-attachments/assets/ebdd8695-c9d8-477b-b5cf-ba6d8d41e84a

Without this change, the test fails, and Odoo incorrectly recomputes the fields, as shown in the video.
<img width="1232" height="515" alt="image" src="https://github.com/user-attachments/assets/27370f1f-e7b7-4102-a606-0181b9d1a97a" />

When the ORM computes fields marked as `precompute=True`, in this function `_add_precomputed_values` https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/odoo/orm/models.py#L4836, `price_unit` is 0, but the records get `price_unit` from the product. Therefore, when [_compute_amount](https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/addons/sale/models/sale_order_line.py#L855) is called, the values are computed with an incorrect `price_unit`.
<img width="1087" height="940" alt="image" src="https://github.com/user-attachments/assets/92feadf0-7f93-4acc-8f1a-931db0655fcc" />

**Steps to reproduce the issue:**

- Install the attached module. [sale_precompute.zip](https://github.com/user-attachments/files/31265993/sale_precompute.zip)
- Configure a delivery carrier as free for orders over 1, and set the fixed price to 5, for example.
- Create a sales order and add a product with a value greater than 1.
- Add the shipping method. The price should be 0. In the sales order line, `price_unit` is 0, but `price_subtotal` and `price_total` are equal to 5 (the product's sale price).

For more context, this module is a simple example extracted from the OCA `product_secondary_unit` module, which adds a mixin with these fields: https://github.com/OCA/product-attribute/blob/18.0/product_secondary_unit/models/product_secondary_unit_mixin.py. In the `sale_order_secondary_unit` module, `sale.order.line` inherits from this mixin.

You can see the error in this PR: https://github.com/OCA/sale-workflow/pull/4535.
https://github.com/OCA/sale-workflow/actions/runs/32259842816/job/96090194021?pr=4535#step:8:509

I understand that this requires a deeper investigation into precompute to solve the underlying issue, but I propose setting `product_uom_id` in the `_prepare_delivery_line_vals` method as a temporary solution while the final solution is being investigated.

I understand that this field should not have been removed from `_prepare_delivery_line_vals`; the referenced PR only renamed the field and did not intend to remove the value from this method.
@Tecnativa @pedrobaeza @kcv-odoo @Feyensv coudl you please review this?

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

Peppol documents can be received in a journal or in the Documents app (peppol_reception_mode). Some companies cannot use Documents: _peppol_allows_document_reception() returns False and the journal stays required. This is the case of French companies (via l10n_fr_pdp).

The onchange of the settings and the import did not check this method. So on a French company with the mode set to 'documents':
  - the Settings cleared the journal on each opening, while it was still required
  - the incoming documents were saved in Documents instead of vendor bills

Steps to reproduce:
- Create a Belgian company, with a purchase journal, and register it on Peppol as receiver
- Set the reception mode to "Receive in Documents"
- Change the fiscal position to France, and install l10n_fr_pdp, the Peppol part is replaced by "French Electronic Invoicing", so the radio button is not visible anymore, but the company still has peppol_reception_mode == 'documents'.
- Open the Settings again: the field "Incoming Invoices Journal" is empty.

opw-6429691

Forward-Port-Of: odoo/enterprise#126462

**Behavior:**
When a sales user without accounting access rights tries to view an invoice created from a sale order where a cash rounding is applied, an AccessError is raised.

This occurs because loading the invoice view triggers `_compute_tax_totals()`, which then passes the invoice's `invoice_cash_rounding_id` to `_get_tax_totals_summary()`. Which then ends up failing when trying to access fields on the `cash_rounding` record  due to missing accounting rights, even though the user is allowed to view the parent invoice.

This is fixed by ensuring reading fields on `cash_rounding` during tax total computation bypasses the access check using `sudo()`, as the user already has legitimate access to the invoice itself.

**Steps to reproduce:**
- As an admin, enable cash rounding then create one.
- Create an invoice and set the Cash Rounding Method
- In debug mode, go to 'Set Default Values' in the debug dropdown and set Cash Rounding Method = your rounding for all users
- Go to users, and ensures that Demo has no accounting rights but has sales user rights
- As Demo, create a sale order, confirm it, then create the related invoice.
- When trying to acces said invoice, you should get an Access Error

opw-6379781

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

Steps to reproduce
---
1. Create a quality control point on the Receipts operation type with Control per set to Operation.
2. Confirm a receipt of 2 units of the product: one pending operation quality check is created.
3. In the Barcode app, receive 1 unit and go back to the transfer with the back button.
4. The pending operation quality check is gone.

Issue
---
Going back from the Barcode app calls `post_barcode_process`, which on a partial reception splits the picked move into a done move and a remaining move, then merges the transient duplicate back with `_merge_moves`. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/stock_barcode/models/stock_move.py#L57-L60

`_merge_moves` cancels that transient duplicate through `_action_cancel` before unlinking it. https://github.com/odoo/odoo/blob/8f3100ca597559945cc42d9ef9517edbb40a900b/addons/stock/models/stock_move.py#L1400-L1401

The `quality_control` override of `_action_cancel`, picks the pending checks to drop from `is_product_canceled`, a `defaultdict(lambda: True)` keyed by `(picking, product_id)`. An operation check has no `product_id`, so its key is never computed by the loop and reads back the `True` default, so it is deleted even though the transfer still has a live move. Since an operation check covers the whole transfer, it must be dropped only when every move of its picking is cancelled. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/quality_control/models/stock_move.py#L68-L76

opw-6439179

Forward-Port-Of: odoo/enterprise#128654
Forward-Port-Of: odoo/enterprise#127427

Clicking the translate button saves the form's root record before opening the translation dialog, since https://github.com/odoo/odoo/commit/9da52919a03dbcee5209430918195158c0652099. A record opened in an x2many form dialog keeps its changes for itself until the dialog is saved, see https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/web/static/src/model/relational_model/static_list.js#L193. Its pending changes are not part of the root record changes, so saving the root sends nothing to the server, and the translation dialog then shows the stored terms instead of the current content, or no terms at all when the stored value is empty.

The fix changes openTranslationDialog in translation_button.js, the place that decides which record to save. When the record keeps its changes for itself (record._noUpdateParent), the record is saved directly, like the button did before the commit above. The root record is still saved in the other cases, so the editable list case that commit fixed keeps working.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app, open a survey and click a question in the Questions tab
3. In the Description tab, change the description
4. Click the EN button on the description field

=> the translation dialog shows the terms of the previous description, not the current one

Ticket [link](https://www.odoo.com/odoo/project.task/6237291)
opw-6237291

Forward-Port-Of: odoo/odoo#269507

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Forward-Port-Of: odoo/odoo#277426

Steps to produce:
---
- Install `sale_management` and `sale_loyalty` module without demo.
- From sales > products > discounts & loyalty, create new loyalty card program and save.
- Now create new product of 100$.
- Create a user which have sales rights as `user: own documents only`.
- With that user, create new sale order with product and confirm.
- Try to cancel the order.

Issue:
---
- It shows the access error: 
```py
You are not allowed to delete 'Sale Order Coupon Points - Keeps track of how a
 sale order impacts a coupon' (sale.order.coupon.points) records.

This operation is allowed for the following groups:
	- Sales/Administrator

Contact your administrator to request access if necessary.
```

Root cause:
---
- Users with the `Sales: Own Documents Only` access right only have read permissions ([1]). When they cancel a Sales Order, the `_action_cancel` method attempts to clean up the temporary pending points allocated to the order by calling `self.coupon_point_ids.unlink()`. Because this call is executed without elevated privileges, the system blocks the deletion and raises an Access Error

Solution:
---
- Added `.sudo()` to the `unlink()` call for `coupon_point_ids` in the `_action_cancel` method. This ensures the pending point records are cleaned up with the necessary elevated privileges.

[1]https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/sale_loyalty/security/ir.model.access.csv#L16

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

Forward-Port-Of: odoo/odoo#283535
Forward-Port-Of: odoo/odoo#281477

**Issue**
Recalculating an invoice after applying a landed cost could lead to a wrong stock variation.

**Steps to reproduce**
- Create 2 products:
	- Product A: valuated using AVCO tracked by quantity
	- Product B: service with landed cost enabled
- Create and confirm a PO for 10 units @ 500 of product A and validate the receipt
- Create and confirm a SO for 3 units of the product A and validate the delivery
- Create and validate the invoice
- Create a Bill for the PO and add 1 unit @ 100 of product B, using the expense account
- Create the landed cost and confirm it and the Bill
- Reset the invoice to draft and confirm it again
-> In inventory valuation, Stock Variation is 30 instead of 0

**Cause**
Each time an invoice is validated, it recompute the cogs values:
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/account_move.py#L29-L37
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/account_move.py#L122
which needs the cogs unit price:
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/account_move_line.py#L68
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/stock_move.py#L275-L280
This returns the standard price (and not the move value) since the product is average-costed but not lot-valuated.

The `move.value` originating from the SO is 500*3 = 1500, since it has been computed before adding the landed cost and stay constant afterwards.

However, the `move.value` originating from the PO becomes 5000 + 100 = 5100.
Indeed, when confirming the landed cost, it recomputes the value of the move:
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_landed_costs/models/stock_landed_cost.py#L152
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/stock_move.py#L323
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/stock_move.py#L441
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_landed_costs/models/stock_move.py#L24
Which updates the standard price to 510:
https://github.com/odoo/odoo/blob/791e5423a73acbef69a5ffe26b3f6036269395f2/addons/stock_account/models/stock_move.py#L356-L359

So there is a discrepancy between the `stock.value` (1500) and the cogs values (510*3=1530),
which explains why the Stock variation is 30.

opw-6416072

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Steps to reproduce:
----------------------------------------
1. Install `whatsapp_sign` and Contact modules
2. Go to Sign > templates
3. Make two sign requests for the same partner
4. Go to partner record and try to change the email (remove or add a character)

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/odoo/enterprise/whatsapp_sign/models/sign_request_item.py', line 101, in _send_signature_access_message
    is_whatsapp = self.sign_request_id.send_channel == 'whatsapp'
  File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1657, in __get__
    record.ensure_one()
  File '/home/odoo/odoo/community/odoo/orm/models.py', line 5942, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: sign.request(3, 4)
```

Issue:
----------------------------------------
In `_send_signature_access_message()` which accessed `self.sign_request_id.send_channel` directly on the full multi-record recordset. When `res_partner.write()` detects an email change, it searches for all sent sign request items of that partner and calls `send_signature_accesses()` on the combined recordset. Accessing `sign_request_id` on this multi-record set resolved to multiple sign requests, and the subsequent field access triggered `ensure_one()`.

Solution:
----------------------------------------
* Refactored `_send_signature_access_message()` to iterate over each item individually, checking `send_channel` per item's own `sign_request_id`. Items are partitioned into `email_items` and `whatsapp_items` batches. Email items are delegated to `super()` and WhatsApp items are processed individually.

* Refactored to cleaner and more readable code and correctly handles mixed-channel recordsets where items may belong to different sign requests with different send channels.

opw-6387586

Steps to reproduce:
- send an image in a Discuss channel
- click the image to open the file viewer
- click the download button

=> Android shows "The Odoo Mobile Apps only supports file downloads
   using the HTTP protocol."

downloadFile()'s GET-by-URL case fetches the URL via XHR, then saves the Blob response by clicking a hidden <a download> anchor on a blob: URL. Android's DownloadManager only accepts http(s) URLs, so it rejects that blob: URL instead of downloading anything.

Patch downloadFile._download to hand the URL directly to a new mobile.methods.saveFile bridge method when available, the same way download._download already delegates to mobile.methods.downloadFile.

Blob/string content downloads aren't handled here — the only such call site (spreadsheet JSON export) is debug-mode only, so this is left as a console.warn for now.

Related to odoo/odoo@e83fd8c08c879f5e262d39f24edcb3f81238ea82

Code made by Claude
Changes supervised by HUVW

Forward-Port-Of: odoo/enterprise#128471
Forward-Port-Of: odoo/enterprise#127693

Before this commit, it was impossible to use budget on the Moroccan P&L, for the following reasons:

- The feature was designed for one-column reports. MA's P&L uses 3, one of which is the total of the two others.

=> We remove that requirement, and make sure to always select the 'balance' column as the reference for the budget comparison.

- When trying to input a budget amount in the report, the amount disappeared entirely.

    => This was because the total column of report was not using 'balance' as its expression label. We fix that by rewriting the expression labels of that report.

The fact we hardcode the use of 'balance' is arguable. It is however not possible here to rely on some custom handler to change a specific option key that would be used to generate the budget comparison data, since some of those data need to be generated in the get_options, before _custom_options_initializer even gets called. This is the simplest approach, and this case is rare enough for us to deem it acceptable.

opw-6385229

Forward-Port-Of: odoo/enterprise#128816
Forward-Port-Of: odoo/enterprise#128266