Currently, an error occurs when a pre-formatted text is directly pasted into the product description using the website editor.

**Steps to reproduce:**
1. Install the eCommerce app.
2. Open the web editor on any product's detail page.
3. Add product description by copy-pasting preformatted text like;
 **Amazing Features** 
 stability, durability, consistency
5. Save the changes.

**Error:**
KeyError - None

**Cause:**
The issue is caused by an invalid HTML structure.
When preformatted/nested block elements are pasted, they get wrapped inside `<p>` block, which is not valid HTML. This leads to missing `data-oe-model` attributes on sub-elements, resulting in an error.

Before saas-18.4, the text block used a `<div>` tag to wrap content. After [this](https://github.com/odoo/odoo/commit/bbb2d98d9ab97ce729d59b9858b63daccf5434e2) commit, the wrapper was changed to a `<p>` tag.

**Fix:**
This commit replaces the wrapper tag with a `<div>` to ensure that preformatted and block-level content can be added and saved.

sentry-6731261789

The system will crash when we get the `category` as `str` and we try to evaluate `int(category)` in `_validate_and_get_category` method.

**Root Cause:-**
- At [1] and [2], we are passing an object in the arguments for the category. If we manually provide a category, it may result in a `not found` error instead of a regular error.
- However, at point [3], Since the `category` is received from a `query parameter`, it can be easily tampered with, so it should be properly validated before use.
- This controller makes the `older controller` (used before V14) `compatible` with the new one.


[1]
https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L470

[2]
https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L247

[3]
https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L546

**Error:-**
`ValueError: invalid literal for int() with base 10: 'duffle-bags'`

**Solution:-**
- We added a `validation` to ensure the category parameter is a `valid integer` before using it.
- This prevents crashes when users manually input 'invalid` or `tampered category` values in the URL.

**Sentry - 6658317828**

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

Forward-Port-Of: odoo/odoo#216791

## Before this commit:
When calculating the `price_unit` for stock moves from purchase order lines, the `remaining_qty` and `remaining_value` could be imprecise. Standard float comparisons for these remaining amounts could lead to incorrect `price_unit` calculations if, for example, `remaining_qty` was a small float near zero. This could result in inaccurate stock valuations, particularly when currency conversions were involved or when landed costs were applied.

For example, 70.00000003 is rounded **up** to 70.00001 (with 5 digits), resulting in a quantity difference of 0.00001, which incorrectly inflates the unit cost.

## After this commit:
Change the rounding method to 'HALF-UP' instead of the default 'UP' to improve precise result for quantities.

## Steps to reproduce:
1. Configure a product with AVCO real time. Set decimal precision for price and UoM to 5 digits.
2. Create a Purchase Order (e.g., 190 units @ $110/unit).
3. Receive 70 units and create a backorder
4. Create and post a bill for the initially received quantity.
5. Apply a landed cost to the picking of the first 70 units.
6. Create a draft bill for the remaining quantity on the PO.
7. Receive the remaining 120 units from the backorder.
8. The product's cost explodes

opw-4705224

Forward-Port-Of: odoo/odoo#217691
Forward-Port-Of: odoo/odoo#208815

Scenario:

- edit navigation bar to "Rounded box menu" (header_boxed_opt)
- select option "Sub Menus" to "On Hover"
- add a mega menu
- outside of editor, hover the mega menu item and move mouse over it

Result: the mega menu content closes before we get to it.

History:

In saas-18.1 and saas-18.2, these menus with the show on hover have been
broken and fixed through different changes:

(A) normal popup menu
(B) all mega menu
(C) mega menu with header_boxed_opt menu bar

Here is the list of commit and what was broken after them:

- 671515811436a01ea8931d4aa92b62608f8aec90 (nov 2024): C
- b9b3a605e0f4c5da3a258c980107d6162da7f44f (jan 2025): A+C
- ddf071267bd8aca341cb9b7481f3153a254212e7 (apr 2025): B+C
- e65d4cf16a2e973482497c3d9d405b566007e705 (apr 2025): C

And hopefully this commit will fix C that happen since in
671515811436a01ea8931d4aa92b62608f8aec90 where we added a !important
margin-top to the mega menu in case of header_boxed_opt header that
is causing issue C.

We do not the the change for a menu inside .o_mega_menu_is_offcanvas
because in this case "header_sidebar_opt" doesn't need the fix and needs
to have a margin-top because:

- it is in the margin-top space that the go back button is
- the height is computed taking into account the margin-top, so if we
  removed it the height of the megamenu+margin-top would not be 100% and
  there would be a gap at the bottom

opw-4876149

Forward-Port-Of: odoo/odoo#217408
Forward-Port-Of: odoo/odoo#214740

### Steps to reproduce:
- Install l10n_hu_edi and witch to Hungarian company
- Have two different rates for EUR<->HUF
- Create a pricelist in EUR
- Create a quotation with the pricelist and confirm
- Validate the delivery on another date (which has a different rate from today)
- In the sale order click "Create Invoice"
- The generated invoice has lines using the rate for today

### Cause:
The field `delivery_date` was `precompute=True` but on creation of the invoice, at the time of the precompute, `line_ids` is still `False`.
So the invoice is first computed without the delivery date so the currency rate used is the one of the invoice date. When the delivery date is written on the invoice, the line balance is not recomputed because it is "protected".

### Solution:
As the field `delivery_date` was implemented in `account_move` for localizations including l10n_hu, there are no reason to contain the fix only to l10n_hu.
So we add the value of `delivery_date` in the dictionnary used to create a new invoice from sale with the method `_create_invoices`. This way the delivery date is there on creation of the invoice and is used for the currency rate.

opw-4756568

Forward-Port-Of: odoo/odoo#209095

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with two lines (eg both at $100), add the tax on both
- Change the analytic distribution on both lines to different values
- Confirm the invoice
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is doubled ($400), the tax amount is correct ($20)

### Cause:
On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution).

The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92).  At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled.

The result of the query have the base amount doubled.

### Solution:
We cannot fix the query as there is no link to find the tax line origin among the base lines.

The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now, it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example.

The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it.

opw-4753676

Forward-Port-Of: odoo/odoo#217569
Forward-Port-Of: odoo/odoo#213751

**Steps to reproduce:**
- Install Accounting + Inventory + Sales apps
- Enable Automatic Accounting in Settings
- Ensure two companies are available
- Set one product category (same for both companies)
    - For company 1 (current) -> FIFO + automatic valuation (`'real_time'`)
    - For company 2 -> FIFO + manual valuation (`'manual_periodic'`)
- Create a storable product for this category
- From company 1:
    - Buy 10 products at 10$ each and receive them (Purchase + Delivery)
    - Sell 15 products at 10$ each and deliver them (Sale + Delivery)
    - Buy 10 products at 10$ (Purchase)
- Switch to company 2 (keep company 1 checked)
- From company 2:
    - Validate the third delivery order (WH/IN)
- Go to Inventory/Reporting/Valuation
- One journal entry is missing for the last move

**Issue:**
During the processing of the SVL in `_run_fifo_vacuum`, the product used its current env context company instead of the one provided explicitly in the parameters. This caused inconsistencies in valuation logic when the method used differed between the given companies, which results in a missing `account_move_id`.

**Fix:**
Ensure that the product is evaluated in the correct company context by using `product.with_company(company.id)` before the valuation logic.

opw-4732067

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

Forward-Port-Of: odoo/odoo#214966
Forward-Port-Of: odoo/odoo#208644

Currently, an error occurs when opening the product in the shop.

Steps to Reproduce:
 - Install the `website_sale` module.
 - Go to `Products`, open any product, navigate to the `Sales` tab, and add at least one `tag`.
 - Go to `Website` > `Shop`, and open the same product.

`AttributeError: 'product.tag' object has no attribute 'visible_on_ecommerce'`

This error occurs when opening a product in the shop. In this commit https://github.com/odoo/odoo/pull/206084/commits/6d0d8d96b603d222de5c099ca090919573d4c761, it was mentioned that the field visible_on_ecommerce has been renamed to visible_to_customers. The error started occurring after this commit https://github.com/odoo/odoo/pull/201019/commits/eac892a4ad7373d18f954afbbcd2f1213ac5f281, 
where the visible_on_ecommerce attribute is used as a tag attribute [1], which causes the error.

[1]- https://github.com/odoo/odoo/blob/850e575b71b04597d31140cec53a596456370325/addons/website_sale/views/templates.xml#L2333

This commit ensures that visible_to_customers is used in place of visible_on_ecommerce.

sentry-6731935669


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

<b>Steps to Reproduce:</b>
1. Go to Settings > Companies > Configure Document Layout.
2. Choose layout Boxed or any layout that horizontally places the company logo and address.
3. Edit the address block choose long string.
4. Save the layout and click Preview Document or print SO or invoice.

<b>Issue:</b>
- Observe in PDF output the long text overlaps into logo or extend outside the layout bound(differ in layouts) — even though enough space is visually available

<b>Cause:</b>
- A previous change in [PR #201198](https://github.com/odoo/odoo/pull/201198) added the text-nowrap class to address blocks to fix a minor wrapping issue. However, this unintentionally caused layout overflow issues with long lines.

<b>Solution:</b>
- Added width to the address block to ensure balanced layout structure.
- Removed text-nowrap from all layouts, as the original issue is now resolved by applying proper width sizing.
- Removed float-end from Boxed layout, as it was contributing to misalignment.

<b>Additional Notes:</b>
All behaviors addressed by  [PR #201198](https://github.com/odoo/odoo/pull/201198) were re-tested to ensure this fix does not reintroduce previous issues.

<b>opw-4764975</b>
<br>
<b>[PR #201198](https://github.com/odoo/odoo/pull/201198) ISSUE : </b>

![image](https://github.com/user-attachments/assets/789e8c9e-0e24-4e2b-8ba6-9421ab02eaf8)
<br>
<b>ISSUE after [PR #201198](https://github.com/odoo/odoo/pull/201198) FIX:</b>

Folder - ![image](https://github.com/user-attachments/assets/176bfe25-ddbc-4774-bed3-b21eddacbb2c)
Boxed - ![image](https://github.com/user-attachments/assets/e45c37f5-8040-47c6-988c-bf2e7a175400)
<br>
<b>After this PR FIX : </b>

![image](https://github.com/user-attachments/assets/f1eb0d39-3e3b-469e-a978-2637107ba606)
![image](https://github.com/user-attachments/assets/df254c8d-8f0c-486f-ac4e-ec04f3b9e8a1)
![image](https://github.com/user-attachments/assets/315d5854-6ea2-4f0d-8a34-e86ea9e020db)
![image](https://github.com/user-attachments/assets/e582845e-2704-413f-af2b-0bf8bd8977a8)

Forward-Port-Of: odoo/odoo#216876

**Steps to reproduce:**
- Install Contact app
- Create a contact with a specific address
- Go to the Map View of the Contact app
- Filter to view the new contact
- Position in the map might be slightly different from given one (when using OpenStreeMap)
- Click on the position marker > `Navigate To` the address is recomputed correctly
- Click on `View in Google Maps` the address given is often wrong

**Issue:**
Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results.

As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results.

**Fix:**
Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps.

opw-4649910

Forward-Port-Of: odoo/enterprise#87430

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with two lines (eg both at $100), add the tax on both
- Change the analytic distribution on both lines to different values
- Confirm the invoice
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is doubled ($400), the tax amount is correct ($20)

### Cause:
On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution).

The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled.

The result of the query have the base amount doubled.

### Solution:
We cannot fix the query as there is no link to find the tax line origin amongst the base lines.

The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example.

The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it.

opw-4753676

Forward-Port-Of: odoo/enterprise#89569
Forward-Port-Of: odoo/enterprise#87404

### Issue:
It is possible to break the followup reports by directly creating entries in the past.

### Steps to reproduce:
- Example on Belgian loca
- Accounting Dashboard > Misc > new Entry with
	- Date far in the past (ie 2024-01-01)
	- Account: "400000 Customers", Partner: "test partner", Debit: 500.0
	- Account: "499000 Suspense Accounts", Credit: 500.0
- Post
- In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified
- Accounting Dashboard > Bank > new with Amount: 500.0
- "Save & Close" then click on it
- In the page "Manual Operations" change the partner to the one from the MISC entry
- Change the Account to "400000 Customers"
- Validate
- The follow-up report is no longer "In need of action"
- Create an invoice with a due date in the future
- The follow-up report is back to "In need of action" with the amount of the invoice
- When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€"

### Cause:
The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€.

The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`.

### Solution:
The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due.

So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`.

opw-4784250

Forward-Port-Of: odoo/enterprise#89627
Forward-Port-Of: odoo/enterprise#87873