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

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

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

…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#265648
Forward-Port-Of: odoo/odoo#264707

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

# 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

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

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

Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
    self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```

Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)

At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.

Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.

Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680

Forward-Port-Of: odoo/odoo#265924
Forward-Port-Of: odoo/odoo#265703

# 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

Refunding a customer account order was introduced by this commit: https://github.com/odoo/enterprise/commit/5a1af0db647563cffcb796a257ad01c0d0c9af91

The goal was to show both the original order and its refund in the settlement list and allow settling them together.

This works in 18.2 where the feature was introduced, but it causes issues in later versions.

The main issues are:
- Refunded order still appears after the full order is refunded and a new order was created and paid by customer account.
- When two orders exist and the larger one is settled first, the second order cannot be settled correctly.

How to reproduce:
- Create OrderA with AmountA
- Create OrderB with AmountB < AmountA
- Settle OrderA
- Try to settle OrderB: it cannot be found
- Settling by amount shows incorrect values due to negative customer_due_total for settlement orders.

The fix:
Restore the original settlement behavior and handle customer account refunds the same way as settlement orders.

opw-6192248

Forward-Port-Of: odoo/enterprise#117520

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

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

This is a backport of [commit](bf86b89f7cdab0ae378a1d897bfef625ccb4cb38).

#### Description of the issue:
A "childList" mutation record with multiple added or removed nodes is transformed and stored as a sequence of individual "add" or "remove" mutations.

Before this commit, each of the resulting "remove" mutations would contain the same previousSibling/nextSibling pair of the original record. The same happened for "add" mutations (in the form of the equivalent operation, e.g.  "append", "after", etc).

This was incorrect, as the previousSibling/nextSibling pair of the original record would not be the same for each added/removed node. Inserting nodes A and B between nodes P and N (previous and next siblings) is NOT equivalent to
[
    insert A between P and N,
    insert B between P and N // wrong,
]
The second resulting mutation does not make sense, as there's already a node A between P and N at this point, so it is ambiguous whether the insertion should should be done between P and A, or between A and N. So the correct equivalence, when converting a batch insertion of nodes A and B between P and N into a sequence of individual insertions, would be:
[
    insert A between P and N,
    insert B between A and N // correct
]

Similarly, when removing nodes A and B, having N an P as their outer siblings, the correct sequence of mutations would be: [
    remove A between P and B, // A's nextSibling is B at this point
    remove B between P and N
]

This incorrect information about siblings in stored mutations would lead, in some cases, to incorrect results when later applying or reverting mutations, as demonstrated by the test added by this commit.

Moreover, a mutation record having both added and removed nodes, when transformed into a sequence of individual mutations, should first contain the "remove" mutations, and then the "add" mutations, as the latter assumes that the original previous and next siblings, as references for inserting point, are siblings between each other, which is only true after the "remove" mutations took place.

task-4678910, 6205143

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

Forward-Port-Of: odoo/odoo#263505

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

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#118062
Forward-Port-Of: odoo/enterprise#117073