### Issue:

The action used in the ` timesheet approval reminder` email template refair to a non existing action.

### Cause of the issue:

The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461

Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45

The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198

opw-5890269

Forward-Port-Of: odoo/enterprise#107440
Forward-Port-Of: odoo/enterprise#107385

Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values.

This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state).

This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period.

The following rules/fields are updated to use the version object:
- Tax Treatment Category
- Additional Withholding Amount
- Extra Pay
- TFN Declaration
- Medicare (Reduction, Exemption, and Levy)
- Training Loans
- NAT 3093 Amount (Tax Offset)
- Child Support (Garnishee and Deduction)

A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates.

Task-5002697

Forward-Port-Of: odoo/enterprise#106550

Steps to Reproduce:
Video Link - https://www.awesomescreenshot.com/video/48861703?key=b2eb19752b965cb72ad3e8a9215631ac
- Install l10n_uk_reports_cis module
- Enter HMRC credentials & Contractor details in the HMRC tab in the UK Company
  record
- Go to CIS Deduction (GB) report under the Reporting menu
- Select the Return Period already given in the report options
- Click on the Send to HMRC button
- Fill in the necessary details in the CIS monthly return wizard
- After that, click on the Send button on the appeared on the wizard
- Traceback will appear

<details><summary>Exact Traceback</summary>
<p>

```
RPC_ERROR

Odoo Server Error

Occured on 100019718-19-0-all.runbot216.odoo.com on model cis.monthly.return.wizard on 2026-02-04 07:21:51 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/orm/domains.py", line 1492, in _value_to_date
    value = parse_iso_date(value)
            ^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/tools/date_utils.py", line 104, in parse_iso_date
    raise ValueError(f"expecting only datetimes with no timezone: {value!r}")
ValueError: expecting only datetimes with no timezone: '2026-01-05T00:00:00.000+05:30'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http.py", line 2275, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 184, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2330, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2545, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 788, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 93, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports_cis/wizard/monthly_return_wizard.py", line 75, in action_send_montlhy_return
    lines = cis_report._get_lines(options)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2678, in _get_lines
    all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 3327, in _compute_expression_totals_for_each_column_group
    current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 3495, in _compute_expression_totals_for_single_column_group
    formula_results = self._compute_formula_batch(column_group_options, engine, date_scope, formulas_dict, current_groupby, next_groupby,
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 3853, in _compute_formula_batch
    return getattr(self, engine_function_name)(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 4010, in _compute_formula_batch_with_engine_domain
    query = self._get_report_query(options, date_scope, domain=aml_domain)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports_cash_basis/models/account_report.py", line 227, in _get_report_query
    return super(AccountReport, context_self)._get_report_query(options, date_scope, domain=domain)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_analytic_report.py", line 154, in _get_report_query
    query = super(AccountReport, context_self)._get_report_query(options, date_scope, domain)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2249, in _get_report_query
    query = self.env['account.move.line']._search(domain)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports_cash_basis/models/account_move_line.py", line 15, in _search
    query = super()._search(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_analytic_report.py", line 239, in _search
    query = super()._search(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/models.py", line 5364, in _search
    domain = domain.optimize_full(self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 445, in optimize_full
    return self._optimize(model, OptimizationLevel.FULL)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 653, in _optimize_step
    children = self._flatten(child._optimize(model, level) for child in self.children)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 608, in _flatten
    for child in children:
  File "/data/build/odoo/odoo/orm/domains.py", line 653, in <genexpr>
    children = self._flatten(child._optimize(model, level) for child in self.children)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 459, in _optimize
    previous, domain = domain, domain._optimize_step(model, next_level)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 971, in _optimize_step
    domain = opt(self, model)
             ^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 1517, in _optimize_type_date
    value = _value_to_date(condition.value, model.env, iso_only=True)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/domains.py", line 1495, in _value_to_date
    parse_date(value, env)
  File "/data/build/odoo/odoo/tools/date_utils.py", line 146, in parse_date
    return parse_iso_date(value)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/tools/date_utils.py", line 104, in parse_iso_date
    raise ValueError(f"expecting only datetimes with no timezone: {value!r}")
ValueError: expecting only datetimes with no timezone: '2026-01-05T00:00:00.000+05:30'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://100019718-19-0-all.runbot216.odoo.com/web/assets/109aabb/web.assets_web.min.js:3190:165)
        at XMLHttpRequest.<anonymous> (https://100019718-19-0-all.runbot216.odoo.com/web/assets/109aabb/web.assets_web.min.js:3196:13)
``` 

</p>
</details> 

Reason:
- Action on the Send button in the CIS monthly return wizard is passing a string with DateTime + TimeZone info into the date_from and date_to, which is raising an error during domain optimization, stating that expecting only datetimes with no timezone.

Solution:
- We are now passing the parsed date with only Date info in the string to options.

Task-5865605

Description:
-----------
When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone
misalignment in work interval calculations.

Steps to reproduce:
-------------------
1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break)
2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1)
3. Create a shift for this employee covering their full working day (8am-5pm)
4. Open the planning gantt view and check the total hours column for that day
5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset)

Root Cause:
-----------
In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison.

Solution:
---------
Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend.

opw-5190244

## Short functional explanation of the error
When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown calendar, the color dot doesn't show. Instead, 'null' appears.

## Reproduction Steps
1. Go to planning and create a shift extended on multiple days for an employee who has a flexible schedule.
2. Click Publish and Send.
3. Click on Actions on the left top side and click Preview.
4. Select the employee you just created the shift for.
5. Click on Preview.
6. It opens a window with the employee's planning. On the left top side, click Month.

### Expected behavior
A shift spread on multiple days should show, with a color dot on the left of the schedule.

### Unexpected behavior
Null appears instead of the color dot. Moreover, the background of the shift has the color of the color dot that should be there.

## Origin of the issue
For employees with specified working schedules, multiple-days shifts are limited to their schedule. Thus, these shifts are split on the working hours of the employee.
But flexible employees have no specified working hours, so the shifts aren't split. This creates multiple day slots. FullCalendar generates different html codes for such slots, which don't contain class ```fc-daygrid-event-dot```, responsible for the creation of the color dot next to the shift schedule. However, even if this color dot isn't created, we still mention it here:
https://github.com/odoo/enterprise/blob/59cec3e8c6a0880178aa93651dca66c367d36841/planning/static/src/js/planning_calendar_front.js#L116 to display shifts. Therefore, we have to create it if it doesn't exist.
__
opw-5437257

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Prior to this commit, creating a multi-action that moved a document to a
new folder and immediately triggered another action (e.g., "Create
Invoice") often failed. This occurred because the security check required
the sub-action to be explicitly embedded (pinned) on the *destination*
folder. Since the record was moved during the process, the subsequent
action failed the security check on the new folder where it wasn't pinned.

This limitation caused confusion for users setting up automation flows,
as the intent of the sequence (Move -> Action) was clear and initiated
from a valid context (the source folder), but strict per-action security
rules blocked execution.

This commit improves the `ir.actions.server` execution logic to support
this pattern by introducing a context-based security sentinel:

1. Entry Point Validation: When a Documents action (root) is triggered,
   the system enforces strict security: the action must be explicitly
   embedded on the record's current folder.
2. Context Inheritance: Once the root action is authorized and begins
   execution, it sets a secure sentinel in the context.
3. Trusted Execution: Any subsequent sub-actions (children) detect this
   sentinel and are allowed to run, regardless of the record's current
   folder location.

This ensures that if a user has the right to start the process (the root
action), they have the right to complete the defined sequence, even if
intermediate steps move the record to a folder where the sub-actions are
not explicitly pinned.

As a result, the `_can_execute_action_on_records` override in
`documents_account` is no longer necessary and has been removed.

Tests have been extended in the `documents` and `documents_account` 
modules to cover these scenarios (using Tags in the `documents`
module instead of Accounting-specific models to make the tests generic).
A new test file `test_documents_ir_actions_server.py` was created
to maintain a clean testing environment, covering nesting, move sequences,
and RPC spoofing attempts.

Task-5916630

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#106315
Forward-Port-Of: odoo/enterprise#100749