…to hours

## Issue:
'request_hour_from' and 'request_hour_to' should be computed using the default
 calendar attendance values, but instead they display 12:00 AM, meaning their
values remain 0.0.

## Steps to Reproduce:

- Open the Time Off app.
- Configure a Time Off Type with the Duration Type (request_unit) set to Hours.
- Set this Time Off Type as the default one while creating a new Time Off.
- Create a new Time Off request.
- Observe that 'request_hour_from' and 'request_hour_to' are not computed and display 12:00 AM (0.0).

## Root Cause:
While fixing the issue related to preserving leave hours when changing Time Off Types, a regression was introduced.

Related PR: https://github.com/odoo/odoo/pull/227235

During the creation of a new Time Off with the duration type set to Hours by default, the field 'request_unit_hours' is already True. This prevents the computation of 'request_hour_from' and 'request_hour_to', resulting in both values remaining 0.0.

## Solution:
Compute 'request_hour_from' and 'request_hour_to' when their values are still 0.0 (initial Time Off creation case), and skip recomputation only when switching between Time Off Types in order to preserve manually entered hours.

Steps to reproduce : [Video](https://drive.google.com/file/d/1P2MFIj8ZxFtFxv2FlX4Zdq6P-5veTxUb/view?usp=sharing)

OPW: 6209992

Forward-Port-Of: odoo/odoo#266104
Forward-Port-Of: odoo/odoo#264707

# How to reproduce
- Start from a fresh database
- Install the account module
- Import companies with a data file. These companies need to have a country set and the
data file needs to contain some bad data
- Click on the Test button

# The problem
An Odoo Server Error is displayed saying : "savepoint xxx does not exist", which prevents
the import or hides other potential error. More importantly, the date is imported even though it was a test run.

# Cause
Importing companies with a country will import their respective l10n modules using
`button_immediate_install()` :
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/odoo/addons/base/models/res_company.py#L319-L322
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L237

This import calls `cr.commit` :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/ir_module.py#L632-L634

The issue is that when importing a data file, we create savepoints :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/models.py#L971-L974

And if an error arise during our import, we rollback to the appropriate save point. Sadly,
commiting erases any existing save point, so a savepoint error is rased and the
data is not rolled back.

The problem stems from the fact that importing module is simply not transactionnal and
`button_immediate_install()` is not expected to be called with a savepoint. This
was already partly adressed by :
https://github.com/odoo/odoo/commit/66dcee9aa70dc72a332fde64dbc802266bbe4a5a

But it did not cover the file importing case

opw-6174983

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

Forward-Port-Of: odoo/odoo#265188

Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d)

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

Forward-Port-Of: odoo/odoo#262148

**Steps to produce:**
- Install `sale_mrp_renting`.
- Enable `Rental Transfers` from settings.
- Create a rental product.
- Create two variants of the product.
- Create a BoM for one variant and set its type to `Kit`.
- Create a rental order using the other variant.
- Try to confirm the order.

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18:  At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from  `_compute_quantity` method. In version 18.2+:  At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

Forward-Port-Of: odoo/enterprise#118207
Forward-Port-Of: odoo/enterprise#114176

Currently, a traceback occurs when the cron "Payroll: Update data" runs after a referenced partner record has been deleted.

Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Switch to ``My US Company``
- Go to Contacts > Delete ``Internal Revenue Service (IRS)`` contact
- Run the cron ``Payroll: Update data``

Traceback:
```py
ValueError: External ID not found in the system: l10n_us_hr_payroll.res_partner_irs
```
```py
ParseError: while parsing /home/odoo/src/enterprise/ saas-19.3/l10n_us_hr_payroll/data/hr_salary_rule_data.xml:322, somewhere inside
```

https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/l10n_us_hr_payroll/models/hr_payslip.py#L12-L21
The issue occurs because the cron ``Payroll: Update data`` calls
``_get_data_files_to_update`` method, which loads
the ``data/hr_salary_rule_data.xml`` file containing a reference to the
deleted partner record at [1]. Since the external ID no longer exists,
loading the XML file raises the traceback.

[1]: https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L484

sentry-7496380516

Problem:
Undo does not work correctly after inserting a table of content when no paragraph follows it.

Cause:
`SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes.

In the table of content case, this creates a loop:
- Attributes are cleared and a history step is added.
- Undo restores only the cleared attributes.
- The selection falls back into the empty paragraph after the table of content.
- `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step.

As a result, undo never reaches the previous user action.

Solution:
Avoid adding a history step in
`SelectionPlaceholderPlugin.onSelectionChange` when the current step is
not modified by any user interaction.

Steps to reproduce:
- Write some text.
- Insert a table of content using `/toc`.
- Press Ctrl + Z.
- Observe that nothing happens and the previously typed text cannot be undone.

task-6216910

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

Forward-Port-Of: odoo/odoo#264743

**Issue**:
When the name of a MO changes before confirmation, the picking origin
may remain incorrect after confirmation.

**Steps to reproduce**:
- Make sure that multi-step route is enabled in the settings
- Configure the manufacturing route as 2-step
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Clone the "Manufacturing" operation type and assign a different Sequence Prefix
- Create and save a MO, without confirming it
- Change and save the operation type to the cloned one (the MO name changes)
- Confirm the MO
-> The picking source document uses the previous MO name instead of the new one

**Cause**:
The source document of the picking (`origin`) comes from its move:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1526
The move origin comes from the procurement values:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1575C13-L1575C56
Which relies on `self.reference_ids[0].name`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1639
which is never updated, causing the origin to keep the previous MO name.

opw-5979778

Forward-Port-Of: odoo/odoo#255874

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#263934
Forward-Port-Of: odoo/odoo#257342

The employment subsidy calculation was incorrect in two main scenarios:

### 1. Incorrect threshold prorating:

The system was comparing the salary against the full monthly limit even for partial periods (weekly or bi-weekly). This resulted in employees wrongly receiving the subsidy when their proportional salary actually exceeded the limit.

Example: In 2026, the 14-day threshold should be 5,292.67 (11,492.66 / 30.4 * 14). Currently, an employee earning 10,000.00 in those 14 days still gets the subsidy because it's being compared against the full 11,492.66.

### 2. Cumulative monthly cap:

When multiple payslips occur in the same month, the total subsidy sometimes exceeds the statutory monthly maximum (536.22 for 2026) because the cap wasn't enforced across all slips.

Example: The 2026 maximum monthly subsidy is 536.22. In a month with three partial payslips:
- Mar 1st - Mar 14th: The system grants 246.68.
- Mar 15th - Mar 28th: The system grants 246.68.
- Mar 29th - Apr 11th: For the 3 days belonging to March, the system grants an additional 52.86.
Total subsidy for March reaches 546.22, exceeding the legal cap.

### Changes included in this PR:
- Updated `l10n_mx_rule_parameter_uma` to include monthly and annual values. This prevents rounding discrepancies.
  Example: the 2026 annual UMA published is 42,794.64. In a rule the calculation is: l10n_mx_uma * 30.4 * 12 = 117.31 * 30.4 * 12 = 42,794.68 resulting in a ~0.04 difference.

- Create a new rule parameter `l10n_mx_rule_parameter_subsidy_salary_limit` to have the subsidy eligible threshold. Starting in 2026, the government's rounding changed from zero decimals(e.g., 9,081.00 in 2024, 10,171.00 in 2025) to two decimals (11,492.66). Storing these as explicit parameters avoids the precision errors.

- Added comprehensive unit tests covering:
  - Complete periods: validates standard payslips aligned with the month calendar (bi-monthly, monthly, bi-weekly).
  - Overlapping periods: validates split-month scenarios (14-day, 10-day, weekly) where periods cross month boundaries:
    Example of self._overlapping_period("weekly", 7, 2646.33, (35.24, 88.10), (3, 123.34), (77.53, 35.24))
    This test covers 5 weekly payslips with the following subsidy
    distribution:
    - Tuple `first_payslip` => (35.24, 88.10) means that:
      First payslip (Apr 29 - May 5), the subsidy is 35.24 for April and 88.10 for May.
    - Tuple `mid_payslips` => (3, 123.34) means that:
      For the next 3 payslips fully in May, the subsidy is 123.34 each.
      Payslip 2 (May 6 - May 12): Subsidy for May = 123.34
      Payslip 3 (May 13 - May 19): Subsidy for May = 123.34
      Payslip 4 (May 20 - May 26): Subsidy for May = 123.34
    - Tuple `last_payslip` => (77.53, 35.24) means that:
      Last payslip (May 27 - June 2), the subsidy is 77.53 for May and 35.24 for June.
  - Across years: subsidy amounts and limits are updated annually.
    Therefore, if a period overlaps two years, a salary amount might be eligible for a subsidy in January but not in the previous December, and the paid subsidy is increased in January due to the new limits.

- Cleaned up redundant tests (test_regular_payslip_subsidy) and adjusted decimal precision.

- For split-month `schedule_pay` periods, the first payslip might generate a subsidy. However, in subsequent payslips, due to commissions or a wage increase, the employee may exceed the monthly subsidy salary limit.
  In those payslips, a warning is shown to notify the user that a manual adjustment is required.
  Created tests to validate these cases.

target: 19.0
task-5419659

Forward-Port-Of: odoo/enterprise#116779
Forward-Port-Of: odoo/enterprise#107601

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#266028
Forward-Port-Of: odoo/odoo#265206

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#265914
Forward-Port-Of: odoo/odoo#264083

# The bug

When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field is used in the `stock_package_m2m` widget to append a `No package` tag when a move has this field set.

https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L266-L269

https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/static/src/widgets/stock_package_m2m.js#L9-L24

This works fine when package history exists, as it accesses the `package_ids` field to generate the tags. However, for recently upgraded databases, no package history is available. When the `_compute_package_ids` method runs, it attempts to access data from an undefined history record, triggering a traceback.

https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L271-L278

# The fix

The fix is straightfoward: in `_compute_package_ids`, if a move is in the `done` or `cancel` state and has no package history, we fallback and populate `package_ids` using the same logic applied to states other than `done` or `cancel`. This behavior specifically targets and fixes issue for databases recently upgraded to v19.

task: 6070541


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

Forward-Port-Of: odoo/odoo#265032

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

Forward-Port-Of: odoo/enterprise#112493

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

Some stock queries determine whether a location belongs to the subtree of a set of locations by checking the parent_path prefix against candidate parent locations. This is done using a correlated EXISTS subquery with a LIKE parent.parent_path || '%' condition.

When the list of candidate locations becomes large (for example tens or hundreds of thousands of ids), this approach causes extremely poor performance because the database must repeatedly compare hierarchical path strings for every candidate row.

This PR improves the performance of this ancestry check by replacing the string prefix comparison with a direct check on the ancestor ids contained in parent_path.

### Current behavior before PR:

The query determines whether a location belongs to the subtree of one of the provided locations using:

location.parent_path LIKE parent.parent_path || '%'

For each row, PostgreSQL must evaluate a correlated subquery against all candidate parent locations. Because this relies on string prefix comparisons on parent_path, when the location list is large, this results in extremely slow queries.

### Desired behavior after PR is merged:

Instead of performing string prefix comparisons, the query extracts the ancestor ids directly from parent_path.

The path is:

1. Trimmed to remove leading and trailing /
2. Split into an array of ancestor ids
3. Expanded using unnest
4. Checked for intersection with the provided location ids

This converts the ancestry check from repeated string comparisons into a simple integer membership check.

### Benchmarks

Comparing performance of old subquery:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM stock_location parent
	WHERE parent.id IN (long list)
		AND stock_location_inner.parent_path LIKE parent.parent_path || '%%'
);
```

to new one:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM unnest(
        string_to_array(trim(both '/' FROM stock_location_inner.parent_path), '/')::int[]
    ) AS path_id(id)
	WHERE path_id.id IN (long list)
);
```

Depending on the number of elements in 'long list'

| # of elements | Before | After |
| --- |---|---|
| 130,000 | 21min | 0.8sec |  
| 10,000 | 95sec | 0.5sec |  
| 1,000 | 10.5sec | 0.5sec |  

In practice, on the reference ticket this causes the "Validate" button on a stock picking to go from timing out to taking 8 seconds. 

### Reference

opw-5932436

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

Forward-Port-Of: odoo/odoo#255399
Forward-Port-Of: odoo/odoo#254245

Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d)

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

Forward-Port-Of: odoo/odoo#262148

**Steps to produce:**
- Install `sale_mrp_renting`.
- Enable `Rental Transfers` from settings.
- Create a rental product.
- Create two variants of the product.
- Create a BoM for one variant and set its type to `Kit`.
- Create a rental order using the other variant.
- Try to confirm the order.

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18:  At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from  `_compute_quantity` method. In version 18.2+:  At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

Forward-Port-Of: odoo/enterprise#118207
Forward-Port-Of: odoo/enterprise#114176

Problem:
In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned.

Cause:
During save, `convert_inline` processes the content via `_normalizeStyle`, which iterates over `CSSStyleDeclaration` using index-based iteration. This only yields longhand properties (e.g. `padding-left`, `padding-top`), never shorthands like `padding`. When the shorthand contains `var()` references (e.g. `padding: var(--y) var(--x)`), the browser cannot resolve the longhands and leaves them empty, so they are silently dropped during style extraction. Adding shorthand support to the iterator was not viable, as the rest of the pipeline expects longhand-only styles, and safely converting `padding: var(--y) var(--x)` to longhands is not possible without first resolving the variables.

Solution:
Replace the `padding` shorthand in the banner template with explicit longhand properties (`padding-top`, `padding-bottom`, `padding-left`, `padding-right`).

Steps to reproduce:
1. Open an email template
2. Add a banner/info block
3. Save the template
4. Reload the page
5. Observe horizontal padding is lost and icon is misaligned

task-6230530

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

Forward-Port-Of: odoo/odoo#265756

Problem:
Undo does not work correctly after inserting a table of content when no paragraph follows it.

Cause:
`SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes.

In the table of content case, this creates a loop:
- Attributes are cleared and a history step is added.
- Undo restores only the cleared attributes.
- The selection falls back into the empty paragraph after the table of content.
- `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step.

As a result, undo never reaches the previous user action.

Solution:
Avoid adding a history step in
`SelectionPlaceholderPlugin.onSelectionChange` when the current step is
not modified by any user interaction.

Steps to reproduce:
- Write some text.
- Insert a table of content using `/toc`.
- Press Ctrl + Z.
- Observe that nothing happens and the previously typed text cannot be undone.

task-6216910

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

Forward-Port-Of: odoo/odoo#264743

**Issue**:
When the name of a MO changes before confirmation, the picking origin
may remain incorrect after confirmation.

**Steps to reproduce**:
- Make sure that multi-step route is enabled in the settings
- Configure the manufacturing route as 2-step
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Clone the "Manufacturing" operation type and assign a different Sequence Prefix
- Create and save a MO, without confirming it
- Change and save the operation type to the cloned one (the MO name changes)
- Confirm the MO
-> The picking source document uses the previous MO name instead of the new one

**Cause**:
The source document of the picking (`origin`) comes from its move:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1526
The move origin comes from the procurement values:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1575C13-L1575C56
Which relies on `self.reference_ids[0].name`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1639
which is never updated, causing the origin to keep the previous MO name.

opw-5979778

Forward-Port-Of: odoo/odoo#255874

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

Forward-Port-Of: odoo/enterprise#112493

__

## Short functional explanation of the error
When checking the dashboard on a project we created with a yearly subscription, the values shown are incorrect.

## Reproduction Steps
1. Create a new product. Check the Subscription field and set the Product type as Service. On the Create on Order field, set Project & Task. Then, in the Recurring Price tab, add a Monthly plan with price 50 and yearly plan with price 40.
2. Create a new Quotation. Set a customer and add the product you just created in an Order line. Set the Quantity to 100 and set the recurring plan as Yearly. You'll see the amount be at 4000, and the total amount at 4600 with taxes. Click on Confirm.
3. Create an invoice and confirm it.
4. Click on the Project smart button. Then, on the top right, click on the view menu > Top Menu. Select Dashboard and click on it.

### Expected behavior
On the dashboard, we should see the Revenues under Profitability at 4000. To invoice should be left at 0 and Invoiced should be at
4000. Expected should be at 4000.

### Unexpected behavior
On the dashboard, To Invoice is at 333, and Expected is at 4333. This corresponds to our invoice + 4000/12 -> monthly recurring plan, with the price of the yearly plan!

## Origin of the issue
We always add the `recurring_monthly` value when showing the profitability, no matter the recurring plan:
https://github.com/odoo/enterprise/blob/cdc0d5d57f6b27a6bb5e451d48bdbef4e3dde5cb/project_sale_subscription/models/project_project.py#L86
We should only add the `recurring_monthly` value for as many monthly
subscriptions we have, not for *all* the subscriptions.
__
opw-5916688

Forward-Port-Of: odoo/enterprise#117818
Forward-Port-Of: odoo/enterprise#113918

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#265914
Forward-Port-Of: odoo/odoo#264083

Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d)

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

Forward-Port-Of: odoo/odoo#262148

Problem:
In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned.

Cause:
During save, `convert_inline` processes the content via `_normalizeStyle`, which iterates over `CSSStyleDeclaration` using index-based iteration. This only yields longhand properties (e.g. `padding-left`, `padding-top`), never shorthands like `padding`. When the shorthand contains `var()` references (e.g. `padding: var(--y) var(--x)`), the browser cannot resolve the longhands and leaves them empty, so they are silently dropped during style extraction. Adding shorthand support to the iterator was not viable, as the rest of the pipeline expects longhand-only styles, and safely converting `padding: var(--y) var(--x)` to longhands is not possible without first resolving the variables.

Solution:
Replace the `padding` shorthand in the banner template with explicit longhand properties (`padding-top`, `padding-bottom`, `padding-left`, `padding-right`).

Steps to reproduce:
1. Open an email template
2. Add a banner/info block
3. Save the template
4. Reload the page
5. Observe horizontal padding is lost and icon is misaligned

task-6230530

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

Forward-Port-Of: odoo/odoo#265756

### Issue:

During migration of Malta taxes, the script can fail when certain tax XML IDs are missing for a company. If the XML ID does not exist, `env.ref(..., raise_if_not_found=False)` returns None. Trying to combine a recordset with None causes the migration to fail. Due to recent [commit]

### Traceback:
```py
    tax_7 |= env.ref(f'account.{company.id}_VAT_S_IN_MT_7_G', raise_if_not_found=False)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6589, in __or__
    return self.union(other)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6603, in union
    raise TypeError(f"unsupported operand types in: {self} | {arg!r}")
TypeError: unsupported operand types in: account.tax() | None
```
### 
Solution:

Use a guard check with the walrus operator (:=) to assign and validate the tax record before union.
This ensures that only existing tax records are added to the recordset, preventing the crash.

Ticket [link1](https://www.odoo.com/odoo/project.task/6159300) [link2](https://www.odoo.com/odoo/project.task/6149387)
opw-6159300 
opw-6149387

Forward-Port-Of: odoo/odoo#264327

### Steps to reproduce:

- In the settings enable: Multi-steps routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with a bom using the MTO Route
- In the Miscellaneous tab of the bom tick Batch Size and set it to 2
- Create and confirm a sale order for 6 units of P
#### > Three MO's are created but only the last one will update the quantities of the delivery at validation of the production.

### Cause of the issue:

The `move_dest_ids` of the `move_finished_ids` is only set on the last of the three productions. That is only the last MO is properly chained to the delivery via an MTO chain. This happens because the `move_dest_ids` field of the `mrp.production` model is a `One2Many` field: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L223-L224 Which implies that each move can be linked to at most one mrp.production via the `created_production_id` field. However, if you have set a batch size on your bom, it is expected for a single move to create multiple mo's. While the `move_dest_ids` of each of these MO is appropriately set in the create vals to be the mto `stock.move` of the delivery, due to the nature of the `created_production_id` field only the *last* mo will created with a set `move_dest_ids` as this is the only record that will be set as `created_production_id`. However, after the creation of these MO's, the related `move_finished_ids` will be recomputed:
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1089-L1093 However, the `move_dest_ids` of the created moves will be set to be either the `move_dest_ids` of their production (which is unset for all but the last one) or these of the first production of the same `production_group` that is these generated by a common production split: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1263-L1267
Now, since neither are set in our use case, the `move_dest_ids` will not be set on the `move_finished_ids` which implies in particular that the mto link between our productions (but the last one) and the delivery is lost.

Fix:

Since we can not change the nature of the `move_dest_ids` and `created_production_id` in stable to become Many2Many fields, we need to find a way to propagate the `move_dest_ids` on moves without relying on the probably inaccurate value provided by the production. And, since the compute of the `move_finished_ids` could be launched at many other points than during a create process (because of the many dependencies), we can not solely rely on the creation context but rather new to provide a way to recreate the link from relations at any given point. We therefore rely on the `stock.reference`'s similar to what was done prior to 19.0 via the `procurement_group_ids`: https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/mrp/models/mrp_production.py#L1198-L1202

opw-6188069

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

Forward-Port-Of: odoo/odoo#264951

Problem:
Undo does not work correctly after inserting a table of content when no paragraph follows it.

Cause:
`SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes.

In the table of content case, this creates a loop:
- Attributes are cleared and a history step is added.
- Undo restores only the cleared attributes.
- The selection falls back into the empty paragraph after the table of content.
- `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step.

As a result, undo never reaches the previous user action.

Solution:
Avoid adding a history step in
`SelectionPlaceholderPlugin.onSelectionChange` when the current step is
not modified by any user interaction.

Steps to reproduce:
- Write some text.
- Insert a table of content using `/toc`.
- Press Ctrl + Z.
- Observe that nothing happens and the previously typed text cannot be undone.

task-6216910

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

Forward-Port-Of: odoo/odoo#264743

**Issue**:
When the name of a MO changes before confirmation, the picking origin
may remain incorrect after confirmation.

**Steps to reproduce**:
- Make sure that multi-step route is enabled in the settings
- Configure the manufacturing route as 2-step
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Clone the "Manufacturing" operation type and assign a different Sequence Prefix
- Create and save a MO, without confirming it
- Change and save the operation type to the cloned one (the MO name changes)
- Confirm the MO
-> The picking source document uses the previous MO name instead of the new one

**Cause**:
The source document of the picking (`origin`) comes from its move:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1526
The move origin comes from the procurement values:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1575C13-L1575C56
Which relies on `self.reference_ids[0].name`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/stock/models/stock_move.py#L1639
which is never updated, causing the origin to keep the previous MO name.

opw-5979778

Forward-Port-Of: odoo/odoo#255874

**Issue**
Replenishment quantity is not rounded when the replenishment UoM is the
same as the product UoM.

**Steps to reproduce**:
- Enable "Units of Measure & Packagings" setting
- Create a tracked product and add a vendor using the same uom (ex: Unit)
- Create a replenishment order rule:
	- min = 0
	- max = 10
	- multiple: Unit
- Create a sale order for that product with 1.11 units
-> It tries to replenish 11.11 units instead of 12

**Cause**:
While computing `qty_to_order`, it rounds using the given multiple via `_get_multiple_rounded_qty`:
https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L471-L475
However, `_get_multiple_rounded_qty` skips rounding when the replenishment
UoM matches the product UoM:
https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L802-L809

opw-[6015189](https://www.odoo.com/web#id=6015189&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#256006

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

Forward-Port-Of: odoo/enterprise#112493

**Issue:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

Forward-Port-Of: odoo/enterprise#117921

### Issue before this commit:
When importing an Italian electronic vendor bill using the AssoSoftware standard, pension fund taxes (Cassa Previdenziale) are not applied to the invoice lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_witholding
2. Change VAT number of IT company with the one in the xml
3. Go to Taxes > 4%F.Pens. > Advanced Options and change Pension Fund Type with TC02
4. Import xml of the ticket in vendor bills
5. P.Fund tax is not assigned

### Cause of the issue:
The issue is caused by the following line:
https://github.com/odoo/odoo/blob/669b9b84f4d5c8765dc4b451d5da6a95dbb9ded8/addons/l10n_it_edi_withholding/models/account_move.py#L247 Currently, the parser strictly expects the optional <RiferimentoTesto> tag alongside <TipoDato>AswCassPre</TipoDato>. However, several third-party software providers generate valid XML files containing only the  AswCassPre block without any optional child tags.

### Reason to introduce the fix:
Ensure that the pension fund tax mapped to the line's VAT rate is correctly applied whenever the AswCassPre data type is present, even if the optional reference tags are omitted.

opw-6189225

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

Forward-Port-Of: odoo/odoo#265914
Forward-Port-Of: odoo/odoo#264083

Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence.

**Steps to Reproduce:(v-19.0)**
1. Install the `accountant` and `l10n_my_edi` modules (with demo data).
2. Switch to "MY Company"(Malaysian company).
3. Enable "_Quick Encoding_" for Customer Invoices in Settings.
4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice.
5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again.
6. Open the invoice list view and click **"Send to MyInvois"**.

**Error:**
`ValueError: not enough values to unpack (expected 4, got 2)`

The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1].

[1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146
Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263

sentry-7320998540

Forward-Port-Of: odoo/odoo#266221
Forward-Port-Of: odoo/odoo#253237

Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d)

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

Forward-Port-Of: odoo/odoo#262148

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

Forward-Port-Of: odoo/enterprise#112493

Creating a bank account with a falsy proxy value generates a traceback.

Steps to reproduce the error:
- Install ``l10n_br`` module with demo data
- Switch to BR Company
- Go to Contacts > Configuration > Bank Accounts > Create a new bank account >
  Add any value as Account Number >  Account Holder: BR Company >
  Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save

Traceback:
```py
InvalidFormat: The number has an invalid format.
```
```py
TypeError: 'bool' object is not iterable
```

https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45
For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value
raises a traceback.

https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61
For ``Random Key`` validation, ``re.fullmatch`` expects a string value,
but receives ``False``, leading to a traceback.

sentry-7488238698

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

Forward-Port-Of: odoo/odoo#264995

# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
	- Name : X
	- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)

# The problem
We see both records even tho we should only see one

# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589

In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601

The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.

opw-6224811

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

Forward-Port-Of: odoo/odoo#265835

Before this commit:
-------------------------
- When planning work orders in the Gantt view, applying a Group By on Work
  Center and then adding another grouping (e.g., Manufacturing Order or
  Status) caused a traceback when clicking grouped rows in the panel.

Steps to reproduce:
-------------------------
1. Install the `mrp_workorder` module.
2. Create and plan a Manufacturing Order.
3. Open the Planning Gantt view
4. Apply Group By → Work Center.
5. Add another group by (e.g., Manufacturing Order or Status)
6. Click on one of the groups (MO or Status) in the side panel.

Cause of the issue:
-------------------------
- Rows grouped by Work Center -> Manufacturing Order attempted to access
  a Work Center record that does not exist, leading to the error:
  `TypeError: Cannot read properties of undefined (reading 'display_name')`
- Rows grouped by Work Center -> Status incorrectly treated the status
  value as a Work Center ID, leading to the error:
  `psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer`

After this commit:
-----------------------
- Rows created directly from the Work Center grouping are now correctly
  linked using their corresponding `workcenterIds` and remain clickable.
- Rows created by additional groupings after Work Center (e.g.,
  Manufacturing Order or Status) are no longer clickable.
- This ensures a consistent interaction flow in the Gantt view and prevents the
  previous errors during filtering.

Task ID: 6132396

Forward-Port-Of: odoo/enterprise#114565

**Steps to produce:**
- Install `sale_mrp_renting`.
- Enable `Rental Transfers` from settings.
- Create a rental product.
- Create two variants of the product.
- Create a BoM for one variant and set its type to `Kit`.
- Create a rental order using the other variant.
- Try to confirm the order.

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18:  At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from  `_compute_quantity` method. In version 18.2+:  At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

Forward-Port-Of: odoo/enterprise#118207
Forward-Port-Of: odoo/enterprise#114176

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
We have two conflicting css styling on mobile:
- `overflow-hidden` was added for mobile to avoid multiple scroll bars
- `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css

This means that the element is present at the bottom of the page, but we can't get to it manually.
When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top).

Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter.

**Fix:**
Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed.

original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd

opw-6061993

Forward-Port-Of: odoo/enterprise#113168

Steps to reproduce:
-----------------------------------
1. Install Subscription module
2. Create and Confirm Subscription Order as follows: * Create 2 SOL with the same product with different quantities
3. Create and Confirm the Invoice of the Sale Order
4. Create an Upsell of the SO
5. Change the First line's quantity to any value (e.g, 3)
6. Confirm the Upsell Order
7. Go back to the original order

Observation:
-----------------------------------
The quantity added in Upsell is added to the quantity of the Second line of the Original Order.

Issue:
-----------------------------------
The `_compute_parent_line_id` method matches upsell lines to their parent lines based on product attributes (product_id, price_unit, product_uom_id, currency_id, plan_id). When multiple parent lines have identical attributes, the matching becomes ambiguous.

The algorithm processes upsell lines sequentially and removes each matched parent from the pool.
https://github.com/odoo/enterprise/blob/4c9682e9cf84a0e4e69b5b650833cbccc77b063e/sale_subscription/models/sale_order_line.py#L336-L337

Without a stable identifier like a sequence, the algorithm takes the LAST matching line arbitrarily, causing incorrect parent-child mappings.

Solution:
-----------------------------------
Using 'sequence' as the matching criteria in `_compute_parent_line_id`, Sequence provides a stable, predictable identifier that preserves line order. Lines with the same product attributes but different sequences will now match correctly based on their position in the order.

Added 'sequence' to line_values in `_get_renew_upsell_values` because the `parent_line_id` field is a COMPUTED field (with `store=True`). When creating upsell lines, even though we set `'parent_line_id': line.id` in the values, Odoo will recompute it using `_compute_parent_line_id`. If we don't preserve the sequence from the parent line, the newly created upsell line will get a default/auto-incremented sequence that doesn't match its parent's sequence. This breaks the sequence-based matching we just added.

opw-6083153