After merging this commit [1], the test sometimes non-deterministically fails on runbot. This PR aims to fix the test. [1]: https://github.com/odoo/odoo/commit/1a2c3c00869fd9702bb9d15e3d38d9c02a3349f5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213540

After merging this commit [1], the test sometimes non-deterministically fails on runbot. This PR aims to fix the test.

[1]: https://github.com/odoo/odoo/commit/1a2c3c00869fd9702bb9d15e3d38d9c02a3349f5



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

Forward-Port-Of: odoo/odoo#213540

The E-way Bill date was previously displayed in the `YYYY-MM-DD` format. ---- **In this commit** - This change updates the date formatting logic to display dates in the `DD/MM/YYYY` format for better readability and consistency in ewaybill report. --- task-4807690 Forward-Port-Of: odoo/odoo#213709 Forward-Port-Of: odoo/odoo#210583

The E-way Bill date was previously displayed in the `YYYY-MM-DD` format.

----
**In this commit**
- This change updates the date formatting logic to display dates in the `DD/MM/YYYY` 
   format for better readability and consistency in ewaybill report.

---
task-4807690

Forward-Port-Of: odoo/odoo#213709
Forward-Port-Of: odoo/odoo#210583

Description of the issue/feature this PR addresses: When fetching videos from vimeo, if the video is deleted, an error is shown to the user which also block test `test_snippet_background_video`. Current behavior before PR: 1. Install website 2. Start `website_snippet_background_video` tour 3. You'll get an error if a video is missing Desired behavior after PR is merged: Now, with the error handling, a warning will be simply outputed for the missing video instead of a blocking mess

Description of the issue/feature this PR addresses:
When fetching videos from vimeo, if the video is
deleted, an error is shown to the user which also
block test `test_snippet_background_video`.

Current behavior before PR:
1. Install website
2. Start `website_snippet_background_video` tour
3. You'll get an error if a video is missing

Desired behavior after PR is merged:
Now, with the error handling, a warning will be
simply outputed for the missing video instead
of a blocking message



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

Forward-Port-Of: odoo/odoo#213631
Forward-Port-Of: odoo/odoo#210307

Current behavior before PR: - Clicking an image inside `<div class="o-paragraph">` opened the text toolbar. This is because the selection traversed a whitespace text node that was not filtered out. Desired behavior after PR is merged: - This fix filters out such nodes to show the correct (image) toolbar. task-4844821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212879

Current behavior before PR:

- Clicking an image inside `<div class="o-paragraph">` opened the text toolbar. This is because the selection traversed a whitespace text node that was not filtered out.

Desired behavior after PR is merged:

- This fix filters out such nodes to show the correct (image) toolbar.

task-4844821



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

Forward-Port-Of: odoo/odoo#212879

Also replace an unnecessary listcomp by a gencomp as the list is not necessary. Though all the callsites seem to go through the entire sequence so likely doesn't do much. Forward-Port-Of: odoo/odoo#213774 Forward-Port-Of: odoo/odoo#213729

Also replace an unnecessary listcomp by a gencomp as the list is not necessary. Though all the callsites seem to go through the entire sequence so likely doesn't do much.

Forward-Port-Of: odoo/odoo#213774
Forward-Port-Of: odoo/odoo#213729

This reverts commit 0b9859f693d4f23d17b0644e8e0b0ad0bb08c843. Scenario: insert the Parallax snippet, open the page in iPhone (tested on safari 14.0 up to 18.5). Result: the image is zoomed highly and doesn't respect background-size:cover property. Issue: having "background-attachment:fixed" in iOS breaks background-size property, and the image is not resized to fit. Fix: restoring 412117c2a789a24191cda040614d01fe290e77cc by reverting 0b9859f693d4f23d17b0644e8e0b0ad0bb08c843 since

This reverts commit 0b9859f693d4f23d17b0644e8e0b0ad0bb08c843.

Scenario: insert the Parallax snippet, open the page in iPhone (tested
on safari 14.0 up to 18.5).

Result: the image is zoomed highly and doesn't respect
background-size:cover property.

Issue: having "background-attachment:fixed" in iOS breaks
background-size property, and the image is not resized to fit.

Fix: restoring 412117c2a789a24191cda040614d01fe290e77cc by reverting
0b9859f693d4f23d17b0644e8e0b0ad0bb08c843 since the fix was still
necessary. This has the drawback that parallax that were working on
non-iOS device will now scroll, but this will be consistent.

opw-4848881

__pr note:__ I rebased on 18.1 since it was the revert original version.

Forward-Port-Of: odoo/odoo#213835

Prior to this commit, headings indentation was inconsistent in some edge cases. Example: ``` <h3> <h2> <h3> <h2> <h3> ``` would appear instead of: ``` <h3> <h2> <h3> <h2> <h3> ``` Desired algorithm: - Indent heading by 1 unit to the right of the previous strictly lower heading, or no indent task-4836337 Forward-Port-Of: odoo/odoo#212380

Prior to this commit, headings indentation was inconsistent in some edge cases.

Example:
```
<h3>
<h2>
  <h3>
  <h2>
    <h3>
```
would appear instead of:
```
<h3>
<h2>
  <h3>
<h2>
  <h3>
```
Desired algorithm:
  - Indent heading by 1 unit to the right of the previous strictly lower heading, or no indent

task-4836337

Forward-Port-Of: odoo/odoo#212380

**Issue** The "Terms and Conditions" section in the invoice report only takes up half of the page, leaving unnecessary blank space on the other half. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Invoices. 3. Create or open an invoice. 4. Add a multiline text in the "Terms and Conditions" field. 5. Confirm and print the invoice report. 6. Observe that the content only fills half the available width. **Expected Behavior:** The "Terms

**Issue**
The "Terms and Conditions" section in the invoice report only takes up half of the page, leaving unnecessary blank space on the other half.

**Steps to Reproduce:**
1. Install the Accounting app.
2. Navigate to Accounting > Customers > Invoices.
3. Create or open an invoice.
4. Add a multiline text in the "Terms and Conditions" field.
5. Confirm and print the invoice report.
6. Observe that the content only fills half the available width.

**Expected Behavior:**
The "Terms and Conditions" text should utilize the full width of the report layout if needed, especially for multiline entries.

**Actual Behavior:**
The text is constrained to half the page, reducing readability and leaving unused space.

**Root Cause**

The issue was introduced by PR #193399, which added the `overflow-auto` class to address a display bug from ticket 4416845. However, this class was applied too broadly, affecting the layout of the "Terms and Conditions" block.

**Fix**
To address this issue, a class is added specifically to the terms and conditions div to control its display.

opw-4698250

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

Forward-Port-Of: odoo/odoo#204801

This new module adds necessary features to support JoFotara properly with the following features: 1. Support for different invoice types and payment methods 2. Demo mode These features were added in a new module in stable, but will be merged with the main module in master. The commit also adds support for reporting invoices in their currency. task-4534862 task-4656902 Forward-Port-Of: odoo/odoo#213783 Forward-Port-Of: odoo/odoo#205890

This new module adds necessary features to support JoFotara properly with the following features:
1. Support for different invoice types and payment methods
2. Demo mode
These features were added in a new module in stable, but will be merged with the main module in master.
The commit also adds support for reporting invoices in their currency.

task-4534862
task-4656902

Forward-Port-Of: odoo/odoo#213783
Forward-Port-Of: odoo/odoo#205890

### Purpose of this PR: - Add `expectElementCount` test helper to wait for elements to appear or disappear before asserting their count. This fixes flaky tests caused by timing issues and animations, especially on slower environments like runbot, in toolbar, link popover, powerbox, tablepicker, tablemenu, and emoji picker tests. task-4849995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213090

### Purpose of this PR:

- Add `expectElementCount` test helper to wait for elements to appear or disappear before asserting their count. This fixes flaky tests caused by timing issues and animations, especially on slower environments like runbot, in toolbar, link popover, powerbox, tablepicker, tablemenu, and emoji picker tests.

task-4849995

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

Forward-Port-Of: odoo/odoo#213090

Steps to reproduce: =================== - Create and save a Sales Order for a product tracked by quantity and without stock. > The forecast icon remains blue. - Click again on the product line. > The icon becomes red, indicating insufficient stock. Cause: ====== These RPC calls that delays the calculation of forecasted_issue: https://github.com/odoo/odoo/blob/saas-18.1/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L52C1-L62C10 Fix: ==== Since forecasted_issue

Steps to reproduce:
===================

- Create and save a Sales Order for a product tracked by quantity and
without stock.
  > The forecast icon remains blue.
- Click again on the product line.
  > The icon becomes red, indicating insufficient stock.

Cause:
======
These RPC calls that delays the calculation of forecasted_issue:
https://github.com/odoo/odoo/blob/saas-18.1/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L52C1-L62C10

Fix:
====
Since forecasted_issue does not depend on these calls, we decided to execute them earlier to avoid the delay.

opw-4776752

Forward-Port-Of: odoo/odoo#209450

Contributor License Agreement for Matias Gibbons I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213504

Contributor License Agreement for Matias Gibbons

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

Forward-Port-Of: odoo/odoo#213504

Added new tax and tax group for the 24% VAT rate effective from 1 July 2025. Updated account.tax.report to include a new line for the 24% VAT rate (Line 1) to ensure backward compatibility with reports generated before 1 July 2025. Updated account.tax.report to include a new line for the 22% VAT rate (Line 1_2). Ensured automatic creation of new taxes and tax groups during module upgrade. Adjusted related tax report data and views reflect the updated VAT rate. Maintained compatibility wi

Added new tax and tax group for the 24% VAT rate effective from 1 July 2025. 
Updated account.tax.report to include a new line for the 24% VAT rate (Line 1) to ensure backward compatibility with reports generated before 1 July 2025. 
Updated account.tax.report to include a new line for the 22% VAT rate (Line 1_2). 
Ensured automatic creation of new taxes and tax groups during module upgrade. Adjusted related tax report data and views reflect the updated VAT rate. 
Maintained compatibility with existing data and reports by preserving the 22% VAT rate for historical records. 

For technical info please see:
https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#213668
Forward-Port-Of: odoo/odoo#207751

Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name. Purpose: When changing the c

Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name.

Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention.

Steps to Reproduce on Runbot:
1. Install Payroll
2. Create a new salary structure with no country
3. Create a new salary rule and enable "View in Payroll reporting"
4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created
5. Change the country set on the salary structure
6. Try to access a payroll report record and a traceback is thrown

opw-4649030

Forward-Port-Of: odoo/enterprise#87464
Forward-Port-Of: odoo/enterprise#83749

When importing a coda statement, in case of globalisation, Odoo doesn't take into account the different levels of details. Instead of that, we keep every lines even if one is already the sum of each detailed lines. According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf Chapter 3.1 Transaction type are communicate like that: - 0 -> simple amount without detailed data - 1 -> amount as totalised by the cus

When importing a coda statement, in case of globalisation,
Odoo doesn't take into account the different levels of details.
Instead of that, we keep every lines even if one is already
the sum of each detailed lines.

According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf

Chapter 3.1

Transaction type are communicate like that:

- 0 -> simple amount without detailed data
- 1 -> amount as totalised by the customer
	- 5 -> detail of 1
- 2 -> amount as totalised by the bank
	- 6 -> detail of 2, simple amount without detailed data
	- 7 -> detail of 2, simple amount with detailed data
		- 9 -> detail of 7

Let's assume this case:

- 1 line with transaction type == 2, amount == 3000
- 1 line with transaction type == 7, amount == 2000
- 1 line with transaction type == 9, amount == 2000
- 1 line with transaction type == 7, amount == 1000
- 1 line with transaction type == 9, amount == 1000

Currently, Odoo will display lines 1, 2 and 4 in case of
split transactions instead of lines 3 and 5.
In case of not split transactions, Odoo sums up the same lines.

With this commit, we keep trace of last line's transaction type to:

- be able to delete it if it has detailed data, in case of split
  transaction
- to sum up only the relevant lines

opw-4619660
opw-4795349

Forward-Port-Of: odoo/enterprise#87392
Forward-Port-Of: odoo/enterprise#85006

Before this commit: === - After accepting an order or marking it as "Food Ready," no order was selected by default. After this commit: === - After accepting an order or marking it as "Food Ready," the respective order is automatically selected by default. task-4442911 Forward-Port-Of: odoo/enterprise#87317 Forward-Port-Of: odoo/enterprise#76356

Before this commit:
===
- After accepting an order or marking it as "Food Ready," no order was selected by default.

After this commit:
===
- After accepting an order or marking it as "Food Ready," the respective order is automatically selected by default.

task-4442911

Forward-Port-Of: odoo/enterprise#87317
Forward-Port-Of: odoo/enterprise#76356

Added compatibility with Estonia tax report version KMD6 that is valid from 1. July 2025. For technical info please see: https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return Forward-Port-Of: odoo/enterprise#87354 Forward-Port-Of: odoo/enterprise#84306

Added compatibility with Estonia tax report version KMD6 that is valid from 1. July 2025. 

For technical info please see:
https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return

Forward-Port-Of: odoo/enterprise#87354
Forward-Port-Of: odoo/enterprise#84306

### Steps to reproduce: - In the settings: Enable `Units of Measure & Packagings` - Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6' - Create and confirm a sale order for 5 pack of 6. > This creates and reserve a delivery for 30 units (5 pack of 6). - Process the delivery in the barcode app and scan a pack of 6 #### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30. ###

### Steps to reproduce:

- In the settings: Enable `Units of Measure & Packagings`
- Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6'
- Create and confirm a sale order for 5 pack of 6.
> This creates and reserve a delivery for 30 units (5 pack of 6).
- Process the delivery in the barcode app and scan a pack of 6
#### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30.

### Cause of the issue:

Since the packaging/uom refactoring, packagings are just uoms. Now, scanning the packaging will launch a call of the `_processBarcode` method. During this call, the existing line will not be be found and considered as an appropriate candidate to be updated since the its prodcut_uom is in Unit and the packaging uom is not: https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1710-L1711 As such, there will be no `currentLine` to update and a new line will be created:
https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1441-L1443

opw-4782296

Forward-Port-Of: odoo/enterprise#86180

…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_i

…Inter-Company sync

### Steps to reproduce:

- With Company B in the settings Enable Inter-Company Transactions
   > Synchronize Sales and Purchase Order
- Sales > Configurations > Sales Teams, Archive all sales team
- With COMP A create a sales team with a set company_id: COMP A
- With COMP A create and confirm a PO with COMP B as customer
#### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B.

### Cause of the issue:

The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals:
https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88
While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record.

opw-4627851

Forward-Port-Of: odoo/enterprise#86528
Forward-Port-Of: odoo/enterprise#83487

**Before this commit:** - Submitting a GSTR-1 return to the GST portal with an empty `hsn` dictionary caused a schema validation error from the portal: {"error_msg": "Error in Json structure validation.", "error_cd": "RET191106"} - This occurred because the generated JSON included the `hsn` key with an empty dictionary, which is invalid as per government schema requirements. - The portal expects the `hsn` field to be absent if no data is available, or to contain valid nested keys an

**Before this commit:**

- Submitting a GSTR-1 return to the GST portal with an empty `hsn` dictionary
caused a schema validation error from the portal:

{"error_msg": "Error in Json structure validation.", "error_cd": "RET191106"}

- This occurred because the generated JSON included the `hsn` key with an
empty dictionary, which is invalid as per government schema requirements.
- The portal expects the `hsn` field to be absent if no data is available, or to
contain valid nested keys and values.

**After this commit:**

- A `ValidationError` is raised when attempting to send a GSTR-1 return with no
HSN data, preventing the generation and submission of an invalid JSON payload.
- This ensures that the `hsn` field is only added to the payload when it contains
at least one section with data.
- Helps avoid unnecessary submission failures and improves user feedback at the
point of action.

task - 4807628

Forward-Port-Of: odoo/enterprise#87326
Forward-Port-Of: odoo/enterprise#86655