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

https://github.com/odoo/odoo/commit/ef4c1350df10c186efec79b1414306e325707549 introduced a new exception `ServerActionWithWarningsError`: https://github.com/odoo/odoo/blob/851c46923332aa13c56fbce3a5ed3c5d37a70c92/odoo/addons/base/models/ir_actions.py#L486-L488
This was not registered as an error_dialog. This led to the frontend displaying the entire traceback instead of an error dialog similar to `UserError` when a `ServerActionWithWarningsError` is raised. This commit fixes it by correctly registering the error in `error_dialog` registry category so a more user friendly dialog is displayed with the error contents.

Thanks @brboi for helping with the fix

### Current behavior before PR:

A traceback error is thrown when a `ServerActionWithWarningsError` is raised. Example:
<img width="1896" height="904" alt="image" src="https://github.com/user-attachments/assets/0bfee329-e6c5-4652-a2ac-d41b763e2bdb" />


Video reproducing it: https://drive.google.com/file/d/1C_aE0d_9bP27f388dB1NJLeWHBpsM7AW/view?usp=drive_link (credits: gavb-odoo)

### Desired behavior after PR is merged:

An error dialog similar to UserError which is easier to understand is displayed

<img width="1906" height="799" alt="image" src="https://github.com/user-attachments/assets/d57c5cab-14f2-4f39-9f0c-b8099e8b0089" />


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

opw-4885670

Forward-Port-Of: odoo/odoo#219977

**Issue**
Using a Greek letter in the journal's sequence prefix causes a traceback error when confirming an invoice

**Steps to Reproduce**
1. Install the Accounting module
2. Navigate to Accounting > Configuration > Journals
3. Open the Sales journal
4. Under the Advanced Settings tab, set the communication standard to "European"
5. Set the sequence prefix to include Greek letters (e.g., "TΠY")
6. Create and confirm a new invoice
7. Observe the traceback error

**Root Cause**
The prefix is used in calculating the `check_digits` via a base-36 to base-10 conversion. This conversion fails for Greek characters, which are not valid in base-36, leading to an exception

**Fix**
Greek letters in the prefix are transliterated to their Latin equivalents before performing the checksum calculation, ensuring compatibility with the base-36 conversion logic

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

Forward-Port-Of: odoo/odoo#212169

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

Currently an error occurs when user try to copy email on a newly created record.

Steps to reproduce:
- Install `hr_recruitment`with demo data.
- Add a random Alias Domain (`Settings > Technical > Email > Alias Domains`).
- Open `hr_recruitment` and on 'Experienced Developer', open the option dropdown (meatball) and click on 'Trackers'.
- Now click on `New` and click the copy email button (without saving).

Error:
`ValueError: Expected singleton: hr.recruitment.source()`

Cause:
- Error occurs due to a recent change in this [commit](https://github.com/odoo/odoo/pull/198995/commits/f8cf1b70e28166c100558d2bf5cbc6d8d3513cc6) that introduced the new copy widget
- The error occurs because the function was called even before the record was saved. This caused the function call to be made with empty recordset that causes the singleton error at line [1].

Solution:
- Made the copy button disabled until record is saved.

[1]: https://github.com/odoo/odoo/blob/679d99b8bd233a1046e3219ddb3e23e8465f6107/addons/hr_recruitment/models/hr_recruitment_source.py#L49

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

Hoot provides us with "time control" features such as "advanceTime", which is useful for testing scenarios where we want to wait for some events to happen (such as a debounced function), but without actually waiting too much.

The way it works is that hoot simply override setTimeout and related functions to keep track of all handlers and their scheduled time. However, this is not enough, as the real setTimeout is still by default called, so it can happen in some tests that when we advance the time by some amount, say 500ms, if the cpu load is very high, then other handlers that are scheduled AFTER the 500ms may have run as well.

To fix this, we can use the freezeTime feature from hoot. It simply give the full control to hoot, and do not call the real setTimeout function.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

_______________________________________
## 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

## Short functional explanation of the error
When selling items in the point of sale module with an invoice, when we check said invoice in the backend, the customer reference field is empty.

## Reproduction Steps
1. Go to Point of sale and open a shop interface. Add a random item to the basket and select a customer.
2. Click on payment, then check Invoice, select a payment method, and Validate.
3. Click on the hamburger menu on the top right and click on Backend.
4. Hover the box of the shop you opened with your mouse. In the top right corner of the box should appear a 3-dot menu. Click on it and click on Sessions.
5. Click on the latest session ID. On the top of the page, click on the "Orders" smart button.
6. Click on the order you just finalized. On the top of the page click on the "Invoice" smart button.
7. Click on "Other info" tab.

### Expected behavior
The Customer Reference field should be filled with the name of the order.

### Unexpected behavior
The Customer Reference field is left empty.

## Origin of the issue
When setting the values for the invoice, the field 'Ref' was absent.

opw-4732492

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

Forward-Port-Of: odoo/odoo#218158

## Short functional explanation of the error
When printing a reception report containing a lot of products, the top row of the pages after the first one is overlapped with its corresponding header in the resulting PDF.

## Reproduction Steps
1. Open the settings. In the inventory section, enable "Reception Report".
2. Create a new quotation and add at least 40 different products. Each product should have at least 1 copy in stock, and the quantity to order must be greater than the quantity we have of this product in stock.
3. Confirm the sales order.
4. Create a new purchase order and add the exact same products you added in the quotation.
5. Confirm the order and click on the "Recept" smart button.
6. Click on the "Allocation" smart button and click on the "Assign all" gray button.
7. Click on print and open the PDF once it finishes downloading.

### Expected behavior
Each row (corresponding to the reception of a product) and its corresponding header is printed properly,  regardless of how many pages constitute the report.

### Unexpected behavior
The PDF has more than one page, and on the top of the second page, the product row is overlapped with the header of its corresponding section.

## Origin of the issue
It comes from an issue with WKHtmltopdf itself:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1524
The report uses the "thead" tag for the headers. However, in some cases, when the header is linked to a table dynamically (with for-each, for
 example), WebKit ignores or breaks the "Thead" behavior.

## Explanation of the fix
I override the default behavior of thead, which repeats the header automatically at each new page, with a new style. Now, the "Thead" special behavior is ignored and treated like ordinary lines. The header isn't shown at each new page anymore, avoiding the overlapping of product rows.


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

Forward-Port-Of: odoo/odoo#215398

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

**PROBLEM**
In the accounting app, when selecting multiples customers, if one of them doesn't have a name, the cron sending the report will traceback.

**STEP TO REPRODUCE**
- On a clean db, install the account_reports module
- From the accounting app, create a new company customer (Customers/Customers)
- From that new company customer form view, add a new contact of type "other" and don't specify a name for it.
- Create an invoice for the company
- From the customer list view, select all, and trigger the action "Open Customer Statements"
- Send -> Print and Send
- Check the console, the cron task should traceback on the template

**CAUSE**
In accout_report.py, we get the name of each selected partners, and we don't check if the name doesn't exist. In the template `pdf_export_filters`, we try to join all the name in a string, it fails because one of the name isn't a string (its value is False because it doesn't exist on the partner record).

**FIX**
When getting the partners names, filter out the partners without names.

opw-4916660

Forward-Port-Of: odoo/enterprise#90154

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

Currently, an error occurs when clear the date_to field from an already created record.

Steps to Reproduce:
 - Install the `sale_commission` module.
 - Go to `Commission Plans` and create a record.
 - Now, clear the `date_from` field and save.

`TypeError: '>' not supported between instances of 'bool' and 'datetime.date'`

This error occurs when we clear the date_to field from an already created record. The error started occurring after
https://github.com/odoo/enterprise/commit/926c8f041b51a04f0153be27cfcc8658a07be5b0 this commit that introduced the daterange widget for the date_from field. And when we clear the date_to field and try to save, it triggers the constraint [1] and raises the error.

[1] https://github.com/odoo/enterprise/blob/377321fd7e7b1b2026734b75c79c74c8947e2e6c/sale_commission/model/commission_plan.py#L64

This commit ensures that the record is saved only if the date_to field is also present in the record.

sentry-6710699656

Forward-Port-Of: odoo/enterprise#88769