Forward-port of: 10550b3c7ad607576dc48eeba4d601184a2f90d4

Scenario:

- configure turnstile in setting
- install website_mass_mailing
- drop the newsletter widget in any page

Result:

In saas-18.3 and over, we get this traceback error and the turnstile
code is not working:

 TypeError: Cannot destructure property 'turnStile' of
 'odoo.loader.modules.get(...)' as it is undefined.

Cause:

- On January 2025, in saas-18.2 and over,
  421c5e5c4ee6271bb1085b43505cc1c28b2cb574 and
  22e777c046521f3f89b62caa5876680beb7f5aba rewrote turnstile
- On April 2025, in 17.0 up to master,
  c48e74f57569a1670fee65d65625488846513d79 uses addTurnstile and
  addSpinner method and the old file
- On April 2025, in saas-18.2 and only saas-18.2,
  10550b3c7ad607576dc48eeba4d601184a2f90d4 fixes turnstile for the
  interaction rewrite

So turnstile still cause an error  with the newsletter widget in
saas-18.3 up to master.

Fix: forward-port the saas-18.2 10550b3c7ad607576dc48eeba4d601184a2f90d4
fix in following versions.

opw-4925771
opw-4933957

Forward-Port-Of: odoo/odoo#219255

Before this PR:
When creating invoices/orders for foreign customers that don't have states defined in their country, both **account.move** and **sale.order** models would incorrectly assign the company's Indian state as the place of supply. This happened because the fallback logic would always use **move.company_id.state_id** without checking if the partner was actually Indian. As a result, foreign customers would be treated as Indian customers in GST calculations, leading to incorrect tax treatment and compliance issues.

After this PR:
Both models now correctly identify foreign customers by checking the partner's country first, before falling back to state-based logic. Foreign customers without states are now properly assigned the foreign state reference (**l10n_in.state_in_oc**) instead of the Indian company's state. This ensures accurate GST treatment where foreign customers are correctly identified as overseas transactions.

Task-4900697

Forward-Port-Of: odoo/odoo#220717
Forward-Port-Of: odoo/odoo#216220

_______________________________________
## Short functional explanation of the error
When setting the unit of measure as packs, the volume of products aren't computed correctly.

## Reproduction Steps
1. Go to settings. In the purchase section, click on Units of Measure & Packagings.
2. Click on new, set the unit name as "pack of 4", and set the quantity of the reference unit at 4. Set the reference unit as "units."
3. Go to products and create a test product.
4. In the inventory tab, set the volume greater than 0.
5. Go back to purchase and click on new. Add a line containing the test product, a set quantity, and set as unit "pack of 4."
6. Confirm the order, click on receive then validate.
7. Click on the reporting tab, then purchase. Set the measure as volume and click on the bar chart button. Then, click on the blue column and click on the row corresponding to the purchase operation.

### Expected behavior
Let's say we set the product volume as 4 m³, and we purchased one pack
 of 4. The total volume would be (product volume) * (number of
 products), which would correspond to 4*4 = 16.

### Unexpected behavior
Instead of 16, the total volume shows 1.

## Origin of the issue
In the code, the volume is obtained with the operation (product volume) / (number of products)


_________________________________________
opw-4871100

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

Forward-Port-Of: odoo/odoo#215605

Currently, an error occurs when sending invoices in bulk.

Steps to Reproduce:
 - Install the `account` module.
 - Go to `Email Templates` and open `Invoice: Sending`.
 - In the `Email Configuration`, uncheck `Default Recipients` and enter 
   `demo@gmail.com` in the `cc` field.
 - Go to `Invoices`.
 - Select multiple invoices and click `Send`.

`KeyError: <NewId origin=33>`

This error occurs when sending invoices in bulk. As mentioned in commit https://github.com/odoo/odoo/commit/058d324855a6e2fe3df51386aa153d46419766bf,
the issue was introduced in commit https://github.com/odoo/odoo/commit/39d1907d77ca9c88431e7e9dc9e8c938c79a2987, where the _compute_alerts method attempts 
to set an alert in the wizard. However,since this is a computed field, the 
wizard record has a NewId and calls the method with a transient record [1]. 
When trying to access record.id, it returns a NewId [2], and later, when this 
NewId is used as a res_id [3],it raises a KeyError.

[1]-https://github.com/odoo/odoo/blob/aff5f006d5b1996ea3ecc67998067cd0e292cf2a/addons/account/wizard/account_move_send_batch_wizard.py#L63

[2]- https://github.com/odoo/odoo/blob/c70bca77d0447b005b3898e1861facc2828475fc/addons/mail/models/mail_thread.py#L2037

[3]- https://github.com/odoo/odoo/blob/c70bca77d0447b005b3898e1861facc2828475fc/addons/mail/models/mail_thread.py#L2084

This commit fixes the above issue by using move_ids._origin, ensuring that the method is 
always called with real records, and removes the changes from the previous commit https://github.com/odoo/odoo/commit/058d324855a6e2fe3df51386aa153d46419766bf.

sentry-6562659542


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

Forward-Port-Of: odoo/odoo#217730

Currently an error occurs when we try to merge data in deduplication.

Steps to replicate:
- Go to: Data Cleaning > Configuration > Deduplication.
- Open any Deduplication Rules > Deduplicate > select any record (Make sure at least one record is available in list view).
- Click `Merge` on top left.

Error:
`ValueError: invalid literal for int() with base 10: 'NaN'`

The error because of a recent [refactor](https://github.com/odoo/odoo/pull/205486) where the data of a `many2one` will be an object rather than an array. (task-[3547961](https://www.odoo.com/odoo/project/49/tasks/3547961))

In `saas-18.3`, `record.data.group_id` (many2one field) was an array, so the line [1] worked perfectly. But starting in `saas-18.4`, after the change, the value became an object instead of an array. Because of that, `record.data.group_id[0]` is now `undefined`, and `parseInt()` returns NaN, which causes the `int()` on line [2] to throw a `ValueError`.

[1] - https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/static/src/views/data_merge_list_view.js#L108

[2] - https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/models/data_merge_group.py#L113


The lines that returns object is [this](https://github.com/odoo/odoo/blob/564348a5172ea98b38c903686c21d007d0e57b48/addons/web/static/src/model/relational_model/utils.js#L517-L523).

This commit solves the problem by accessing the ID using `.id` instead.

sentry-6739344848

PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs

SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal

Example:

    If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
    If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)

Current:

    Renew in into yearly: 100% of MRR change -16.67 = -$16.67
    New monthly 80% of MRR change $100 = $80
    Total = 63.33 (modifié)

New

    New monthly 80% of MRR change $100 = $80
    Transfer 1 : 80% of MRR change -100 = -$80
    Transfer 2 : 100% of MRR change +100 = +$100
    Contraction of MRR: 100% of MRR change -16.67 = -$16.67
    Total = 83.33


Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.


taskid-4783929

Forward-Port-Of: odoo/enterprise#88646

If applied, this commit will make so that when a user uses the layout of a template document on a new document, the radio buttons will stay linked.
 _____________________________________________________ 
Using the layout of a template document, containing radio buttons, on a new document will unlink radio buttons, making them useless.

1. Go to the Sign module, and click on the Templates tab.
2. Click on the "Upload PDF" purple button, and upload a PDF of your choice.
3. On the left side of the screen, there's a panel where we can drag and drop sign items. Drag and drop a Radio button. 2 buttons will automatically show, and a yellow link will appear between the buttons. This link indicates that, when a user opens the document to sign, when clicking on a radio button, the other one will automatically be unselected if previously selected.
4. Save and return to the Templates window.
5. A new row has appeared with the name of the document. On the right side of this row, hover the house next to the share button and click on the 3 dots. Then, click on Use Layout.
6. Upload a PDF of your choice.
7. When the PDF shows, there's no yellow link between the radio buttons, unlike on the template from which the layout was used.

In the file sign/models/sign_document.py, in the method _copy_sign_items_to(self, new_document), we copy every sign item from the template to the new document. However, the copy method we call doesn't take into consideration the special link between radio buttons, replicating the buttons correctly but not the link. This link is expressed by the radio set to which the radio buttons belong: indeed, after the copy of sign items, each radio button belongs to a different radio set, separating them.

 ### Explanation of the fix
The fix consists of a rework of the _copy_sign_items_to method and a brand-new method specifically used to copy radio buttons. To keep the link between them, we assign all the buttons of the same set on the original documents to the same brand new radio set. The first button is copied normally: this creates a new radio set. Then, for the remaining buttons, we call copy_radio_item, to which we pass the button created first to use the information the next buttons will share with it.

______________________________________________________________
 opw-4842590

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

Forward-Port-Of: odoo/enterprise#87536