Steps to reproduce:
1. Install documents and sales
2. Check product document centralization from settings, and no alias should be set
3. Now go to setting>techinical>emial>aliases>remove default filter and  check total count
4. Go to products and add a document from the smart button
5. Now again check the aliases total count (1 increased)
6. Delete the document on the product.
7. Alias is not deleted
8. Try to add an alias from the settings

Issue:
- When `documents_product` is installed and product document centralization is enabled, deleting a `product.document` can leave an orphan `mail.alias` resulting in an error while creating a new alias.

Cause:
- A product document owns an `ir.attachment`, and that attachment is mirrored as a `documents.document` for `product.product` / `product.template`. In 18.0, `documents.document` inherits `mail.alias.mixin`, so the mirrored document also owns a `mail.alias`.

- Deleting `product.document` deletes its `ir.attachment`. The linked
  `documents.document` is then removed by SQL `ondelete='cascade'` on
  `attachment_id`, not through ORM `unlink()`. Because the document unlink logic
  does not run, the alias cleanup from the mail alias mixin is skipped.

Why not reproducible in 19.0:
- In 19.0, `documents.document` uses `mail.alias.mixin.optional` instead of `mail.alias.mixin`. Binary mirrored documents no longer create a `mail.alias` unless an `alias_name` is explicitly set, so product mirrored documents do not create aliases in the first place.

Solution:
- Override `ir.attachment.unlink()` in `documents`. before deleting attachment,
  collect linked document aliases then delete attachment. SQL cascade deletes
  linked documents.document rows and now we delete collected aliases.


opw-6019294

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#122038

### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses: 
**Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client keeps the `active_id` and `active_model` of the alias in the context. The "Tickets" smart button action maps this incorrect `active_id` to `default_team_id`.

**Solution:** Update `get_empty_list_help` in `helpdesk.ticket` to validate the context. We can check if the `active_model` is actually `helpdesk.team`. If it's not, we can safely ignore the invalid `default_team_id`.

### Current behavior before PR: 
The system blindly trusts the polluted `default_team_id` and attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message. Because a team with that ID does not exist, it throws a MissingError.

### Desired behavior after PR: 
The system should be able to detect when there is incorrect context and clear the invalid ID before attempting the database lookup. Therefore, the empty tickets view will load correctly without crashing.

opw-6395638

**Steps to reproduce:**
* Install **l10n_fr_pdp** module.
* Create two companies: one French (with PDP activated) and one in another country (e.g. Belgium).
* Create a customer invoice in the **non-French company** for a **French customer**.
* Open **Send & Print** and try to send via **email**.

**Observed behavior:**
* Sending fails with: `Errors occurred while creating the EDI document (format: France UBL 2.1 E-Invoicing Format):` `- The following partner's SIREN or SIRET is missing: <BE company name>` `- The following partner's PDP identifier is missing: <BE company name>`

**Cause:**
* `_get_suggested_invoice_edi_format()` on `res.partner` returned `'ubl_21_fr'` for any French B2B partner regardless of which company was sending the invoice.
* This caused `ubl_21_fr` to be stored as the partner's `invoice_edi_format` and selected at send time, even when the sending company has no PDP registration.
* The `ubl_21_fr` XML builder then validates that **both** supplier and customer have French PDP credentials (EAS 0225, SIREN/SIRET), which the non-French company cannot satisfy.

**Fix:**
* In `_get_suggested_invoice_edi_format()`, add a guard on `self.env.company._get_peppol_proxy_type() == 'pdp'` so that `'ubl_21_fr'` is only suggested when the active company is a PDP-registered French company.

**Note:**
* No test added — reproducing this bug requires two localization modules to be installed simultaneously (e.g. `l10n_fr_pdp` + `l10n_be`), which is not supported in the standard test framework.

opw-6392253

**Steps to produce:**
- Install the `sale_stock` and `sale_management` modules.
- Create a product with the Invoicing Policy set to `Delivered quantities`.
- Create a Sales Order for 5 units of the product, confirm it, and validate the delivery.
- Create and post the customer invoice for the 5 units (SO status is now Fully Invoiced).
- Return 3 units from the validated delivery, click on the `Return for Exchange` option, and validate the transfer.
- Observe the Sales Order's invoice status from the list view.

**Issue:**
- The Sales Order status erroneously switches to `To Invoice` instead of remaining `Fully Invoiced`.

**Root cause:**
- When a return picking is validated with return exchange, the `qty_delivered` on the `sale.order.line` drops immediately. This causes `qty_to_invoice` (`qty_delivered - qty_invoiced`) to become negative from [1].
- And then from [2], the invoice status is set as `To invoice`.

**Solution:**
- Adjust the existing `_compute_invoice_status` override in `sale_stock` to account for pending replacement moves generated during exchange returns. If the replacement quantity offsets the negative `qty_to_invoice`, keep the order `Fully Invoiced` instead of marking it `To Invoice`.

[1]https://github.com/odoo/odoo/blob/b0fc5668990c42f129432dd7eeeb24a042d4b153/addons/sale/models/sale_order_line.py#L1006
[2]https://github.com/odoo/odoo/blob/b0fc5668990c42f129432dd7eeeb24a042d4b153/addons/sale/models/sale_order_line.py#L1041

**opw-6299909**

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

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

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

Forward-Port-Of: odoo/odoo#276774

Steps to reproduce the bug:
- Install l10n_ke_edi_oscu_stock
- Run Test_sale_mrp_kit_bom_cogs

Problem:
```self.assertAlmostEqual(stock_out_aml.credit, 1.53, msg="Should not include the value of consumable component")
AssertionError: 3.07 != 1.53 within 7 places (1.5399999999999998 difference) : Should not include the value of consumable component
```
The test delivered 1 whole unit of every component of Kit A regardless of the fractional quantity actually needed to produce a single kit (0.34/0.14/0.2 units for Component A/B/BB respectively). This went unnoticed under the default invoice_policy 'order', since qty_delivered never drives the invoiced quantity in that case.

l10n_ke_edi_oscu_stock forces invoice_policy to 'delivery' for storable products that have no explicit company_id, which is the case for the products created in this test. With invoice_policy 'delivery', _compute_kit_quantities() correctly reads the over-delivered components as enough stock to form 2 complete kits (min ratio 2.94, floored to 2) instead of 1, doubling the invoiced quantity and the resulting COGS (3.07 instead of 1.53).

runbot-243633

### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses: 
**Issue:** When navigating from an email alias to its parent document, the context incorrectly retains the `active_id` and `active_model` of the alias. This causes subsequent smart button actions on the parent document to evaluate using the wrong ID.

**Solution:** Update the context dictionary returned by the `action_open_parent_document` method. We set `active_id` and `active_model` to match the parent document in order to ensure that the web client drops the outdated alias data.

### Current behavior before PR: 
Clicking a smart button (ex. "Tickets") on the parent document evaluates the action using the old alias ID. Because that ID does not actually belong to the target model, the database search fails and causes a MissingError.

### Desired behavior after PR: 
The context will accurately update with the parent document's ID and model upon navigation. All subsequent smart button actions should receive the correct ID, allowing the views to load normally without crashing.

opw-6395638

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

### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses: 
**Issue:** When navigating from an email alias to its parent document, the context incorrectly retains the `active_id` and `active_model` of the alias. This causes subsequent smart button actions on the parent document to evaluate using the wrong ID.

**Solution:** Update the context dictionary returned by the `action_open_parent_document` method. We set `active_id` and `active_model` to match the parent document in order to ensure that the web client drops the outdated alias data.

### Current behavior before PR: 
Clicking a smart button (ex. "Tickets") on the parent document evaluates the action using the old alias ID. Because that ID does not actually belong to the target model, the database search fails and causes a MissingError.

### Desired behavior after PR: 
The context will accurately update with the parent document's ID and model upon navigation. All subsequent smart button actions should receive the correct ID, allowing the views to load normally without crashing.

opw-6395638

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