## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#122740
Forward-Port-Of: odoo/enterprise#120740

Issue:
Voice transcript 'share by email' button would get post the transcript summary to the chatters of all records of a given model.

Steps:
1) install crm and ai
2) activate openai and gemini by saving the api keys inside settings. 3) create 2 crm leads in order
a) lead 1 and lead 2
4) go into lead 1 and in the description then type in '/voice-transcription'. 5) Go into the 'transcription' section of the voice transcription 6) type something and save
7) then click 'start recording'
8) click 'stop recording' - it doesn't need to actually record 9) wait to process
10) click the 'share by email' button
11) check lead 2 for a message created (there shouldnt be one) 12) go back to lead 1 and click the 'share by email' button 13) check lead 2 again and a second message appears. that is becuase it makes a new mail.compose.message with res_ids of a list of multiple crm.lead.id (e

This was fixed in 19.2+ with the pr https://github.com/odoo/enterprise/pull/115978. But it didnt make it in 19.0 and 19.1

Fix:
default_res_ids: model?.config.resIds, -> default_res_ids: [model?.config.resId] take the single record id instead of the list res_ids

opw-6285883

Forward-Port-Of: odoo/enterprise#121021

Issue
-----
When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well.

Problematic case 1
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a different french delivery address
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> Commercial invoice `Sold To` uses the delivery address

Solution for case 1
-----
Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases...

Problematic case 2 (caused by case 1 fix)
-----
- Create a belgian company
- Setup UPS
- Create a French customer
	- Add a delivery address in Switzerland
- Create a product (with some weight)
- Create a SO (with UPS delivery) to the customer & confirm
- Validate the transfer

> UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.`

Solution for case 2
-----
Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO).

Warning looks like this (on SO):
<img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" />

-----
Ticket:
opw-6200263

Forward-Port-Of: odoo/enterprise#121340
Forward-Port-Of: odoo/enterprise#118031

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product invoiced on delivered quantities with timesheet tracking
- Create and confirm a SO for quantity 1
- Log 20h on timesheets
- Invoice the SO
- Create a credit note for 11 hours => only 9 hours are invoiced
- Log 5h more on timesheets
- Back to the SO > create invoice again
> All the 25hrs are to invoiced, although 9 of them were invoiced before

### Cause of Issue:
When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line.

The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186

### Fix:
Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice.

opw-6253650

Forward-Port-Of: odoo/odoo#273156
Forward-Port-Of: odoo/odoo#268025

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273839
Forward-Port-Of: odoo/odoo#271119

The below test sometimes fail for an incorrect reason and leads to a false 
positive:
https://github.com/odoo/odoo/blob/6dbeac3a42f46b42c638c05aea8285452c944c3f/addons/stock_dropshipping/tests/test_purchase_order.py#L21

Here is another way to reproduce the issue with a higher probability of 
false positive (and it is actually easier to read and understand what the 
test is doing and what's wrong). It needs to edit the following test:
https://github.com/odoo/odoo/blob/ec58c5e12987401659ea0d75d3be2905ad1d807d/addons/purchase_stock/tests/test_create_picking.py#L953
With the below diff:
```diff
--- a/addons/purchase_stock/tests/test_create_picking.py
+++ b/addons/purchase_stock/tests/test_create_picking.py
@@ -965,6 +965,7 @@ class TestCreatePicking(ProductVariantsCommon):
             'price': 500.0,
             'discount': 10,
         })]
+        self.product_id_1.standard_price = 1.0
         po = self.env['purchase.order'].create(self.po_vals)  # create a PO for 5 units
         po.button_confirm()
         with Form(po) as po_form:
```
It will lead to:
```
Traceback (most recent call last):
  File ".../test_create_picking.py", line 976, in test_average_cost_updated_after_po_with_discount
    self.assertEqual(self.product_id_1.standard_price, 450.0)
AssertionError: 1.0 != 450.0
```

Here are the explanations: when receiving an AVCO product, at some point, we 
recompute its standard price. To do so, among several operations, we take 
the last manual update, and we ignore all previous SM:
https://github.com/odoo/odoo/blob/2dbd88657395da965125c8f085da93e04c9c8f0a/addons/stock_account/models/product.py#L463-L465

This is an issue when things are done too quickly. See the pattern:
```py
self.product_a.standard_price = 5.0 # -> define valuation_from_date
po.confirm() # with another cost
receipt.button_validate() # -> define move.date
``` 
In case of a fast execution, both dates will be equal. We therefore ignore 
the SM and rely on the manual update to define the standard price, which is 
not expected. This explains the above `AssertionError`.

Fixing the codebase is quite tricky since the opposite use case could also
happen, aka first processing a receipt and only then modifiying the standard
price.

Tests side, a more important solution should probably be implemented to ease
their redaction and avoid this basic pattern. Yet, a WIP task is changing
the valo for Odoo 20, so the whole logic may change. Second, the current
issue is impacting a lot of builds, so we need to move forward. For both
reason, the commit only "fixes" the current test.

runbot-939955

Forward-Port-Of: odoo/odoo#273078

### Issue:
When creating a new Indian company, the `Half Up` cash rounding is reassigned to the new company instead of being duplicated
Previous Indian companies lose access to it, causing errors when opening invoices that reference the cash rounding if the user doesn't have access to that company

### Cause:
`cash_rounding_in_half_up` was defined as a `data` record with a fixed XML ID (`l10n_in.cash_rounding_in_half_up`) `_get_in_account_cash_rounding` referenced that XML ID directly and set `company_id` to the current company on each chart of accounts installation
This reassigned the single shared record to the new company instead of creating a new one

Moving the definition to the `@template` decorator without a module-prefixed XML ID lets the chart of accounts system create one record per company, as intended

### Steps to reproduce:
- Install `l10n_in` and switch to `IN Company`
- Check the Cash Rounding records grouped by company
- Create a new Indian company
- Enable both `IN Company` and the new company
- Check the Cash Rounding records grouped by company again

Before the fix, only the last created Indian company has the Cash Rounding record

opw-6318857

### Steps to reproduce:

- Have a company with a branch say "company1" and "branch"
- Create two products: Final product (FP), Component (Comp)
- Set the company_id of FP to "branch" and of Comp to "company1"
- Associate both products with a product category set to avco in company1 (the field is company dependant)
- Create a bom for FP with company_id set to "branch": 1 X Comp
- Impersonate a user whose only allowed and default is "branch"
- Create and confirm an MO for 1 unit of FP
- Set the qty_producing to 1 unit and validate
#### > Access Error: Access to unauthorized or invalid companies.

### Cause of the issue:

Validating the MO will, validate the component move and set its value: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/stock_move.py#L168-L173 But, in order to determine this value, it is necessary to determine its `property_cost_method`:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L60-L69
Now, the issue is that the `product_template` of the component belongs to "company1" so that the user is unauthorized to read the valuation method of the product category for "company1".

opw-6216141

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

Forward-Port-Of: odoo/odoo#272429