## **Steps to reproduce:**

1. Create a Service product with Create on Order set to Task and Project set to Field service project.
2. Create a Sales Order containing a storable product and a service product.
3. Confirm the Sales Order to generate the project, task, and delivery order.
4. Validate the delivery order.
5. Create and validate a return for the delivery.
6. Create a return of the return to deliver the products again, but do not validate this new delivery.
7. Open the related task and click on Mark as Done button.

## **Issue:**

In a delivery -> return -> return of return workflow, the stock move goes into this code
https://github.com/odoo/enterprise/blob/59b86f106862c3a364ba633a1580d9051f2fe7ca/industry_fsm_stock/models/project_task.py#L89-L90 the traversal repeatedly revisits the same stock moves through move_dest_ids, causing the loop to alternate between the same move recordsets indefinitely. As a result, the loop never terminates, eventually exhausting the memory and raising a `MemoryError`.

## **Solution:**

Track the stock moves that have already been visited and continue the traversal only with unseen destination moves.

Runbot Video : [Video](https://drive.google.com/file/d/1wiqggjx8T-Mtl4T1JgCsfwBbgQU18nYF/view?usp=drive_link)

OPW - 6420961

Forward-Port-Of: odoo/enterprise#125962

When opening reports with `default_opening_date_filter='this_year'`(e.g., P&L, Partner Ledger), the date filter dropdown showed incorrect defaults for non-selected period types:
- Month showed the last month of the fiscal year (e.g., December)
  instead of the current month
- Quarter showed Q4 instead of the current quarter

This happened because `initDateFilterState()` used the backend's `date_to` (fiscal year end) as the reference for computing all filter periods. For `this_year`, `date_to` is the year-end date (e.g., 2026-12-31), so `computePeriodRange()` for month/quarter returned periods containing that date rather than today's date. Reports with `this_month` or `today` defaults were unaffected because their `date_to` is naturally close to today.

Now, non-selected filters use today as their reference date on initial load whenever today falls within the report period, while the selected filter continues to use the backend's `date_to`, preserving the alignment behavior introduced in the date filter refactor (https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7).

Additionally, selecting the custom comparison filter now triggers an immediate reload so its default date range is recomputed by the backend. The custom comparison range is initialized using the current fiscal year up to today, capping its end date to today instead of inheriting the report's `date_to`, which could otherwise default to a future date for yearly reports.

task-6229588

Forward-Port-Of: odoo/enterprise#127316
Forward-Port-Of: odoo/enterprise#121638

Bug :
	- create an unvalidated leave
	- on the payrun Time view, when validating the view -> click on continue -> error popup appears says you have unvalidated leave (BUG 1)
	- on the payrun Payslips view, when canceling a payslip , the KPIs values don't change unless you refresh (BUG 2)

Reason :
	- PayRunMixin now subscribes to its model's "update" bus event and forwards it to updatePayRun, so any pay run view whose model emits "update" keeps the summary in sync.

	- The natural trigger is the model's "update" bus event, but the mixin never listened to it. On top of that the relational payslip list never even emits "update" on a programmatic reload: model.load() (cog actions) and root.load() (form close, view-button reloads) rebuild the reactive root without calling notify(), which only fires on search/pager changes. The Time view gantt already worked around this because GanttModel.fetchData() calls notify() itself. 

Fix :
	- Subscribe payroll mixing to the "update" notif that will come from the underlaying models.
	- override the onRootLoad hook in payslipListCOntroller to call notify() which sends an "update" message when loading the data.(added a guarderail: only call the notify on the model if it's mounted)

task - 6387933

Forward-Port-Of: odoo/enterprise#125194

Every gantt that needed to display employees without records (without
leaves, attendances, etc.) would implement their own
`_get_gantt_data_group_by_employee()` function. They all do the exact
same thing.

This PR creates the reusable function
`_get_gantt_data_with_empty()`, so that all the
`_get_gantt_data()` functions can reuse that one. That function will
guess the relation model from the `groupby` variable.

`user_domain` (in the context) is supposed to contain the domain defined
by the user (in the search bar). It was not the case for all gantt
views, and produced inconsistent results, as that domain is used to know
when to display the employees without leaves/attendances.

The PR fixes that issue by creating the `HrGanttModel` class, that takes
care of defining the `user_domain` correctly.

This class also disables the *Group By* menu, and defaults to grouping
by employees. This was decided for the following reasons:
- All gantt views inheriting this class would group by employee
- Grouping by other fields would already not work in some cases
- It's very difficult to add employees without records if the gantt is
grouped by multiple fields at once

task-5502544

Steps to reproduce
---
1. Configure a `delivery_easypost` shipping method using the DHL Express carrier.
2. On an international delivery, use Put in Pack to create two or more packages.
3. Validate the delivery.

Issue
---
Validation is blocked with `DHLExpress: rate_error -- DHLExpress multi-shipment rate includes this shipment.`

For an EasyPost multi-shipment order, DHL Express returns the aggregate rate on the first (master) shipment only and adds an informational `rate_error` on the order stating that this rate already covers the whole order, so the remaining shipments carry no rate of their own. The message is not a real error, but `send_shipping` raises on any carrier message whose type is not exempt: https://github.com/odoo/enterprise/blob/534b42def8ae5dc884da4398377f828c49557d6e/delivery_easypost/models/easypost_request.py#L359-L364

`_post_process_ship_response` already detects and clears exactly this harmless message, but only for a hardcoded carrier allowlist introduced in a2de5bc5a14 (`Purolator`, `DPD UK`, `UPS`) that was never extended to DHL Express, so for DHL Express the message survives, reaches the raise, and aborts an otherwise valid shipment: https://github.com/odoo/enterprise/blob/a2de5bc5a14f99b8674c3ee234e4d221b406da0f/delivery_easypost/models/easypost_request.py#L416-L434

`DHL Express` is added to that allowlist so the harmless multi-shipment `rate_error` is posted on the picking and cleared instead of raised. The guard still requires a single `rate_error` carrying the "multi-shipment rate includes this shipment." text with the rate present only on the master shipment, so genuine DHL Express errors keep blocking validation.

opw-6450365

Forward-Port-Of: odoo/enterprise#127164