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

*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#220292
Forward-Port-Of: odoo/odoo#219389

**Current behavior:**
Creating a purchase order in a foreign currency and billing the
product prior to reception will produce 2 issues:
A) The bill line for the product will only make a conversion of
1 single unit of the product with the defined currency exchange
rate, making the amount on the line incorrect when qty > 1

B) When the receipt is finally validated, there will be an
unwanted exchange difference on the journal items generated due
to asymmetrical rounding for the bill AMLs and receipt valuation
AMLs

**Expected behavior:**
Correct bill line currency amounts and symmetric rounding.

**Steps to reproduce:**
1. Set the company currenct to IQD, make a product invoiced on
ordered qty, for sake of example set cost to 500 IQD

2. Create a currency exchange record to USD with a company rate
of `0.00756`

3. Create a PO for 13 of the product created in step 1, with a
discount of 1%

4. Confirm the PO and create the bill -> post it

* Issue A) look at invoice line, see only 1 unit in the
converted currency amount is accounted for by the `balance`

5) Receive the product -> look at the journal items generated
and see that there is a diff of 0.185 IQD

**Cause of the issue:**
A) commit: 90158f6 added a method to try and calculate an AML
balance from its purchase line values, but mistakenly is using
`qty_received` instead of `qty_to_invoice` which explains why
this issue only presents for the bill-before-receipt flow

B) commit: 9f046d5 is using `round=False` context for
`AccountTax.compute_all()` when the expected key is `round_base`

**Fix:**
A) Replace `qty_received or 1` with `qty_to_invoice`
* Also make the test added in 90158f6 more robust

B) Add `round_base=False` alongside the `round` key (not
removing as that existing one could have become expected in this
context)

opw-4689170

Forward-Port-Of: odoo/odoo#216898
Forward-Port-Of: odoo/odoo#205850

**Current behavior before PR:**

**Issue 1:**

- Paste a content with multiple `<li>` elements without `ol/ul` tag, each `<li>` having a paragraph element inside.
- Try to create a list from these elements.
- List is created with wrong element structure.

The problem occurs because when pasting multiple `<li>` elements without an `<ol>/<ul>` tag, `sanitizeNode` replaces existing `<li>` elements with new `<p>` elements. Since each `<li>` already contains a `<p>`, this results in paragraphs being nested inside other paragraphs. As a result, creating the list from these paragraphs leads to an incorrect structure.

**Issue 2:**

If there are multiple paragraph selected along with newline character nodes `(\n)`, it is not possible to remove bold or italic
format from selected content using toolbar. The issue happens because `isSelectionFormat` method fails to give correct value if traversed nodes contains one or more newline `(\n)` characters.


**Desired behavior after PR is merged:**

**Issue 1:**

Now, if an `<li>` contains a `<p>`, the `<li>` is unwrapped instead of creating a new paragraph, resulting in a correct element structure when creating a list.

**Issue 2:**

Now, `\n` nodes are filtered from traversed nodes so that format can be removed from selected content.

task-4752385

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

Forward-Port-Of: odoo/odoo#217361
Forward-Port-Of: odoo/odoo#208127

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

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

**PROBLEM**
1. When setting up a product with vendor that sell the product in different packaging, when triggering the reorder, the PO use the stock UoM instead of the replenishement UoM.
2. Once the first issue is fixed, we can notice the packaging quantity in the picking order is not exactly what it should be (rounding error of 0.01).
3. Once the first issue is fixed, there is a failing test concerning the manufacture procurement route.

**STEP TO REPRODUCE**
1. activate the UoM and packaging option.
2. create a product with a vendor that sells it in a packaging.
3. create a reordering rule with the replenishement UoM being the packaging unit.
4. trigger the reordering, notice the PO doesn't use the right unit and the picking doesn't use the right packaging.
(Same steps to reproduce, just revert my change on stock_move.py before)
(To reproduce the 3rd issue, run the test in odoo/addons/sale_mrp/tests/test_sale_mrp_procurement.py)

**CAUSE**
The procurement for the reordering rule is always created with the stock UoM.
The `_compute_packaging_uom_qty` method doesn't specify the rounding_method to use when converting from the product uom to the replenishment uom.
By default, it uses the 'UP' method.
The _run_manufacture method has a bug: when there is a new procurement for a product that has already a mo opened, it will try to update the mo quantity.
To do so, it calculate a new quantity, by adding the previous quantity and the procurement quantity, but it assumes the quantity is in the product default uom which is not always the case (for example, when there is a replenishment UoM set on the reordering rule).

**FIX**
1. If a remplenishement uom exists on the reordering rule, we create the replenishement with this unit instead of the stock one.
2. Use the 'HALF-UP' rounding method, to reduce the rounding error.
3. Converting the procurement quantity into the product default UoM before computing the new mo quantity.

opw-4858992

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

Issue:
The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created.

Solution:
Create it in the post init hook.

Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed.

Also, make the code a little bit more robust:
* instead of mixing "default misc journal" and vat return journal logic, just use one logic
* the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one
* the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any.
* Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook.

When Debug requests is enable on the whatsapp business account and
user replies with the file, a traceback will appear.

Steps to reproduce the error:
- Install ``whatsapp`` and ``contacts``
- Create a whatsapp business account > Enable Debug requests
- Create a contact > Add a phone number > send whatsapp message with any whatsapp template
- Now reply with the file(ex. pdf or image) in message from the contact's whatsapp.
- Traceback in terminal

Traceback:
``ValueError: A string literal cannot contain NUL (0x00) characters.``

https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166
Here, ``message`` contains NUL (0x00) characters because user replies with
the file, value for the ``message`` comes from the below response.

response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57

Here, ``res.text`` contains NUL (0x00) characters.
So, it will lead to the above traceback.

sentry-6314521165

Forward-Port-Of: odoo/enterprise#83274

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

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

**Steps to reproduce:**
- Install `point_of_sale`.
- Go to POS -> configuration -> settings
- Search 'Operation type' -> open picking type -> Disable `Create new`
- Create a storable product 'test' with serial tracking.
- Add on-hand quantity with serial numbers.
- In POS, select the product and choose one SN,
- Select it again and choose another SN.

**Observation:**
- The order line should have 2 quantities with a list of Serial numbers chosen by the user. For one quantity, it's working fine, but for multiple quantities, an issue occurs.

**Issue:**
- While confirming edit serial numbers popup for multiple quantities, it checks whether each selected SN is valid or not.
- The condition is that the entered SN is in the existing available SNs option. But the already chosen SN is not in the existing SN option,
- Also, creating a new SN is disabled, so it's considered an invalid input.
https://github.com/odoo/odoo/blob/876b7337eb689e0682ab48e9e833f9f0dc6bb8d2/addons/point_of_sale/static/src/app/store/select_lot_popup/select_lot_popup.js#L190-L193

**Solution:**
- Added a condition to allow SNs that are already selected (matched by name and ID) to be considered valid inputs.

opw-4865902

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

Problem:
Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`.

Cause:
The button snippet editor should be disabled if the button is changed to a link. However, `updateOptionsUIVisibility` is only triggered on click events. In this case, the element type changes through the editor itself, not by clicking, so the UI isn't updated accordingly.

Solution:
Trigger a `click` event on the link element programmatically to call `updateOptionsUIVisibility` and hide the button snippet editor when the element is no longer a button.

Steps to reproduce:
- Drop a button snippet
- Click inside the button to edit
- Notice the Button snippet editor appears
- Change the type to "Link" instead of "Primary"
- The Button snippet editor is still visible
- Click the floppy disk icon (save) in the snippet editor -> A traceback occurs

opw-4936796

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

Forward-Port-Of: odoo/odoo#219660

## [FIX] core: python3-magic vs .doc/.xls/.ppt

[python3-magic](https://packages.ubuntu.com/noble/python3-magic)/[python-magic](pypi.org/project/python-magic) (apt/pip) is a frontend for [libmagic](https://manned.org/man/ubuntu-noble/magic) the library that can introspect files to determine their types.

The Documents app makes heavy usage of our mimetypes utilities to scan and fix the extensions of files uploaded by portal users. Everytime a portal user uploads a `.doc`/`.xls`/`.ppt` file, python3-magic is gonna guess the mimetypes `application/x-ole-storage` or `application/CDFV2` which are the mimetypes of the generic file format that Microsoft Office was using until 2006.

The problem is that there is no specific extension for those two mimetypes as Microsoft was using the same file format for many of its office applications.

In this work we enrich python3-magic's detection with our own, which is able to tell different `application/x-ole-storage` and `application/CDFV2` files apart.

**Please note**: Excel files are detected only when the entire file is present. Excel files uploaded via the Documents app are not detected because Documents only `guess_mimetype` on the first 1kiB of the document.

We also added a condition to keep the .doc/.xls/.ppt extension in case the generic `application/x-ole-storage` or `application/CDFV2` mimetype is guessed. Before it was emitting a warning due to the unknown extension.

## [FIX] core: python3-magic vs new (2025) .xlsx files

[python3-magic](https://packages.ubuntu.com/noble/python3-magic)/[python-magic](pypi.org/project/python-magic) (apt/pip) is a frontend for [libmagic](https://manned.org/man/ubuntu-noble/magic) the library that can introspect files to determine their types.

The Documents app makes heavy usage of our mimetypes utilities to scan and fix the extensions of files uploaded by portal users. Sometypes when portal user uploads a `.xlsx` file, python3-magic fails to detect the Microsoft Excel 2007+ (OOXML) mimetype and instead guesses a generic `application/zip`. Technically this is not wrong, OOXML files (like Java JAR and Python Weels) are using the zip format.

This is quite strange because python3-magic is able to work with `.xlsx` files. I'm guessing that Microsoft deployed a new version of Excel and that magic doesn't correctly guess the new (2025) `.xlsx` files. Using a hex editor, the old (from our unittests) and new (from a 2025 support ticket) seem similar: OOXML files, deflate compression, same files present. They are a bit different, in the old the `[Content_Types.xml]` file comes last, in the new it comes first. The zip headers are different too, the old uses zip Data Descriptors, the new doesn't.

The problem is that the Documents app uses the guessed mimetype to "fix" the extension of the uploaded file. So the portal-user's `file.xlsx` gets wrongly rewritten to `file.zip`.

We first used an approach similar to the previous commit[^1], to use our own detection of OOXML files. It works great in base where we run the detection on whole files. However it doesn't work for the Documents app because it attempts to guess the mimetype only reading the first 1kiB of the uploaded file.

A first PR odoo#213647 suggested to change Documents to load the whole file first, and then run `guess_mimetype`, but was rejected.

In this work, we made so we don't fix the extension of zip-like files should the guessed mimetype be application/zip.

[^1]: [FIX] core: python3-magic vs .doc/.xls/.ppt

opw-4607156
opw-4753670

**Issue:**
When closing a PoS session with negative balances, the closing difference is displayed in the chatter box with an excessive number of decimal digits.

**Steps to Reproduce:**
1. Install the Point of Sale app.
2. Navigate to Point of Sale > Open a new session.
3. Set the Opening Cash to 496.45.
4. Add a product priced at 65.86 to an order.
5. Confirm the payment via Payment > Cash > Validate.
6. Close the session and set Counted Cash to 560.40.
7. Navigate to Orders > Sessions.
8. Open the last closed session.
9. Observe that the closing difference is displayed with more than two decimal digits.

Expected Behavior: The closing difference should be rounded to two decimal places for clarity.

Actual Behavior: The closing difference is displayed with excessive decimal digits.

**Root Cause**

Floating-point arithmetic in Python causes small precision errors when performing calculations involving monetary values. Since Odoo's Monetary fields are based on float types, operations such as balance calculations retain unnecessary decimal places instead of rounding them correctly to two digits.

**Fix**
To prevent this from happening, at the moment of crafting the message to display on the chatter, it is explicitly requested to only show two decimal digits of the rounded closing difference.

Opw-4483487

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

Forward-Port-Of: odoo/odoo#199082

Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`.

Steps to reproduce:
---
- Install `Accounting` module(without demo)
- Enable `Analytic Accounting`
- Create a New company and switch to it
- Select both companies and Open `Analytic Distribution` and click `New`

Traceback:
---
`TypeError: 'bool' object is not subscriptable`

At [1], we are searching by `account_type`, but if `Fiscal Localization` is not set for the current company, there will be no records in `account.account`. However, due to the multi-company setup, it still return accounts from the first company. In such cases, the `code` field is empty, which causes the `code` to be treated as False.

[1]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/account/models/account_analytic_distribution_model.py#L55-L58

sentry-6754820454

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

<b>Steps to Reproduce:</b>
1. Install Sales and eCommerce modules.
2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon.
3. Navigate to Website → Shop, search for the product and open its page.
4. Zoom in or out.

<b>Issue:</b>
- The ribbon on the product image becomes misaligned (shifts away from the image) when zooming in or out 
on the product detail page. This results in a broken visual layout.

<b>Cause:</b>
- A previous change in [PR #175473](https://github.com/odoo/odoo/pull/175473) unintentionally replaced 
the height class (h-100) with width (w-100) on ribbon container, causing layout instability during zoom operations.

<b>Solution:</b>
- Restore the proper layout by reintroducing h-100 to both the ribbon container and inner image div. 
This ensures the ribbon stays correctly positioned relative to the image regardless of zoom level.

<b>opw-4854217</b>

<b>Before FIX :</b>
![image](https://github.com/user-attachments/assets/caace073-9605-4d30-afcc-a470acd54e3c)
<b>After FIX:</b>
![image](https://github.com/user-attachments/assets/9206699b-9c39-4748-8398-d8cf9ae6ab9a)

<b>Version:</b> - 18.0

<b>Steps to Reproduce:</b>
1. Log in as Admin.
2. Install the Expenses module.
4. Go to Users > Select or Create an internal user:
   - Create an Employee for the user (if not already done).
   - Ensure Expenses is set blank.
5. Log in with this user.
6. Go to Expenses > Create a new expense.
7. Add a name and total, click "Create Report", then "Submit to Manager".
8. Go back to the expense and attempt to attach a receipt.

<b>Issue:</b>
- A traceback is raised when trying to attach receipt after submitting the report.

**Cause:**
- When setting the main attachment, the method _message_set_main_attachment_id tries to filter on
mimetype assuming it's always a string. If the attachment has False value for mimetype, this leads to
AttributeError: 'bool' object has no attribute 'endswith'.

**Solution:**
- Safely check whether the attachment exists before calling _message_set_main_attachment_id. 
This avoids passing an empty recordset and prevents triggering the downstream error.


<b>opw-4760255</b>