# Steps to reproduce
- Open Timesheets
- Go to list view
- Refresh page
- Total is formatted as regular float instead of time

# Cause of the issue
The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget.

Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`).

We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh.

task-5907954

Forward-Port-Of: odoo/enterprise#107203
Forward-Port-Of: odoo/enterprise#107006

Versions
--------
- 19.0+

Steps
-----
1. Install the Rental and Inventory apps.
2. Go to the rental schedule.
3. Observe the gantt view is grouped by product by default.
4. Remove the product groupby filter.

Issue
-----
The product groupby filter reappears.

Cause
-----
The base gantt view defines `default_group` as product. Additionally, the `sale_stock_renting` module overrides the
`sale_renting.action_rental_order_schedule` action to add two default groupby filters: `search_default_groupby_product` and `search_default_groupby_reserved_lot`.

This creates conflicting defaults: one from the gantt view directly (groupby product) and another from the context (groupby product and reserved lot).

Since lots are disabled by default, the lot groupby filter is ignored. When removing the product filter, the framework falls back to `default_group` and reactivates the product groupby filter.

Solution
--------
Remove the `default_group` parameter from the gantt view. Ensure all actions using the gantt view define their own defaults via context.

opw-5887837

Forward-Port-Of: odoo/enterprise#107008

Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
      The same problem happens if the number of leaves taken is not an integer

Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves.
	- on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee.
	- now click on action button -> Departure: Holiday Attests, you'll see that the employee has 19 allocated instead of 19.5

Reason :  The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.

Fix : Create two new float fields leave_count_float and leave_allocation_count_float to replace their corresponding integer fields.

task - https://github.com/odoo/enterprise/commit/5461268c9411d36feac90cd45dcff42aab59599b

Forward-Port-Of: odoo/enterprise#103258

### Steps to reproduce:

- Enable debug mode (to trigger a traceback rather than a silent error)
- In the settings, enable `Work Orders`
- Create an MO for a product without a BoM
- Add an operation to be performed in a workcenter
- Confirm the MO and open the Shop Floor
- Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display
- Click on `Add component` and add any valid component via the catalog

#### > Traceback: `OwlError: Got duplicate key in t-foreach`

### Cause of the issue:

The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72

Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice:
https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188

However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47

Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected.

In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error.

opw-5417887

Forward-Port-Of: odoo/enterprise#106200

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/62f59f87a513a86a61f871ca743e7f7b04926a82/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1086-L1093

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#107372
Forward-Port-Of: odoo/enterprise#105763

Currently, an error occurs when user edits a reconciled line.

**Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):**

 - Install the `Accounting` module.
 - Create an `invoice` with an `invoice line` having an amount greater than zero.
 - `Confirm` the invoice.
 - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice.
 - Click `Reconcile` on that `statement line` and select the newly `created invoice line`.
 - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save.

`UnboundLocalError: local variable 'original_base_lines' referenced before assignment`

The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2].

This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error.

[1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394

[2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411

sentry-7189027839

## Summary

Previously, only individual files could be selected as sources. This PR introduces **source hierarchies**, allowing users to select and manage entire collections of content as RAG sources. Supported hierarchies include Documents folders, and Knowledge articles with parent–child relationships.

## What’s New

###  AI Agent Source:  Cleanup and Improvements
-  Simplified the status update flow for sources, ensuring more reliable transitions between "Processing," "Indexed", "Failed" and "Incomplete" states.
- Decoupled Knowledge article processing from the `ir_cron_process_sources`  to improve performance and provide more immediate feedback during source creation.
- Implemented cached URL fetching to reduce redundant  requests and introduced standardized error templating for better troubleshooting and translation support.
- Introduced sources hierarchies allowing sources' folder structure.

###  Documents: Folder Support
- Users can now select entire **Documents folders** as RAG sources.
- All valid binary documents within selected folders are automatically extracted.
- Sources are represented as a **hierarchical structure**, mirroring the folder layout.

###  Knowledge Articles: Hierarchical Selection
- Introduces a new wizard: **`ai.add.knowledge.articles`**, replacing the previous article selection flow.
- Users can select **parent articles** and optionally include all **child articles** via a toggle.
- The parent–child structure is preserved in the source hierarchy.

###  Source Synchronization (Reprocess / Retry)
Source hierarchies can now be synchronized across all source types:

- **Documents**
  - Syncs hierarchy when documents are created or moved within folders.
  - Content is re-synced if a document is updated or its version changes.

- **Articles**
  - Updates parent–child relationships when articles are created or moved.
  - Folder sources automatically collapse when parent articles no longer have children.

###  UI Improvements
- The document selection dialog now supports **folder selection**.
- Reuses the same dialog component as the one used in the chatter for consistency.

---

**Task ID:** 5153669

*=account_fiscal_categories_fleet,l10n_lu_reports,l10n_ro_saft

This commit applies vendor bill and fixed asset improvements,
mainly creating new depreciation model, new asset fields on accounts,
and new process to create assets from bills.

Changes:

- New `account.depreciation.model`

New `depreciation_model` is created, which contains the asset method,
duration, and factors. Previously, the concept `asset model` existed
as an asset in `account_asset` with `state` as `model`. The old asset
model concept has been removed and consequently the fields and views
have been removed from the `account_asset` model.

- `account.account` asset changes

Asset fields were removed from `account.account` and new fields were
added. Previously, the account contained fields: `create_asset` and
`asset_model_ids` which were used to indicate how an asset gets created
when account is used in a vendor bill. These fields were replaced by
`depreciation_model_id`, `asset_depreciation_account_id`, and
`asset_expense_account_id`. An asset is created automatically when using
account in bill only if these fields are set. These fields can only be
set on accounts with type `fixed asset`. The Automation tab has been removed.

- Changes to vehicle in accounts

A new field `is_vehicle_account` is added to account to indicate if a
vehicle is required when using account to create an asset.

- New process for creating assets from bills

If an account that has a `depreciation_model_id` is used, then it will
automatically create and validate an asset with default depreciation model,
depreciation account, and expense account as in the fixed asset account. The
user has the ability to only change the default depreciation model, before
creating the asset, from the invoice line. A new JS custom widget was created
to display the fixed asset account, depreciation model, and vehicle in same
cell in the invoice lines. These fields are required and used when creating
an asset. Every invoice line can create only 1 asset even if the quantity is
more than 1. The functionality of multiple assets per line has been removed.

- New method

A new depreciation method is added: No depreciation, to be used when
asset doesn't depreciate. Depreciation model, asset, and account form views
were adjusted to make some fields invisible if method is no depreciation.

task-5240457

This PR improves the UX of calendar and appointment with multiple commits:

- Commit 1 improves the appointment.type form by allowing modifications of reminders when clicking on their tag. It also improve the UX of the calendar.event forms by requiring resources when the appointment type is schedule based on them, changing the display of a button and adapting the code to modifications done in calendar in the community PR.
- Commit 2 improves the UX of the gantt view by changing the date format on the "day" scale and fixing the hotkey of the "New" button. It also improves the calendar view by displaying the share button's messages inside toasters and adapting the code to modifications done in calendar in the community PR.
- Commit 3 adapts the appointment code to allow simple and appointment calendar events to have different default alarms.
- Commit 4 adds a message in the log's calendar.event when whatsapp-type reminders are sent.
- Commit 5 allows appointment calendar events to have activities.

Community PR: https://github.com/odoo/odoo/pull/242504
Upgrade PR: https://github.com/odoo/upgrade/pull/9344

Task-5429852

*: easypost, shiprocket, starshipit

The proper syntax for buttons with icons is to use the icon="" keyword instead of manually defining the font within a class attribute. When it is implemented via the class attribute any string attribute on the button appears in some random sarif font instead of the standard odoo text font.

Before / After
Easypost
<img width="256" height="127" alt="image" src="https://github.com/user-attachments/assets/56cae398-ea49-4961-b599-eab493efa02f" /> <img width="301" height="130" alt="image" src="https://github.com/user-attachments/assets/11c7bf47-41c3-4c18-b218-7d61831ae2cb" />

Shiprocket
<img width="213" height="101" alt="image" src="https://github.com/user-attachments/assets/caaef053-7209-41e8-a0aa-46e3ba018cd9" /> <img width="217" height="116" alt="image" src="https://github.com/user-attachments/assets/940c753f-06a8-4ce0-95a9-b8c2024aa9eb" />

Starshipit
<img width="365" height="141" alt="image" src="https://github.com/user-attachments/assets/861671b8-77d0-44c2-bc27-bb68d638788a" /> <img width="361" height="144" alt="image" src="https://github.com/user-attachments/assets/382deef4-8251-47fc-8ae4-66786da01506" />

Before this commit, we were using the partner name identified by the OCR on previous documents to help with the matching of the partner on next bills.

The intended use case was the following:
- User parses a bill from "SNCB" with the OCR.
- OCR identifies "SNCB" as the supplier, but this vendor is encoded as "Societe Nationale des Chemins de fer Belges" in the database, so it isn't able to match it.
- After the user manually sets the proper supplier and validates the bill, it creates a link from OCR partner name "SNCB" to "Societe Nationale des Chemins de fer Belges".
- From this link, the OCR knows that when it finds "SNCB" as supplier, it needs to set the vendor "Societe Nationale des Chemins de fer Belge".

The issue with this kind of matching is that, if the OCR finds an incorrect vendor name (which is quite frequent unfortunately), it can match completly unrelated partners.

Instead, we will now rely solely on the layout ID identified by the OCR to perform this kind of match as it is much more reliable.

task-[5340130](https://www.odoo.com/odoo/project/2068/tasks/5340130)

Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
      The same problem happens if the number of leaves taken is not an integer

Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves.
	- on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee.
	- now click on action button -> Departure: Holiday Attests, you'll see that the employee has 19 allocated instead of 19.5

Reason :  The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.

Fix : Create two new float fields leave_count_float and leave_allocation_count_float to replace their corresponding integer fields.

task - https://github.com/odoo/enterprise/commit/5461268c9411d36feac90cd45dcff42aab59599b

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1] and [2], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

These checks are intentionally implemented in both modules because they apply
at different stages and for different providers:
1) `l10n_co_dian`
When `DIAN: Free service` is selected as the `Electronic Invoicing Provider`
from the `Invoicing Settings`, the date constraint is evaluated at `send time`.
After the invoice is created, the validation is performed when the user sends 
the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the 
invoice date is outside the allowed range.

2) `l10n_co_edi`
When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same 
rule is checked `at the confirmation time` of the draft invoice. In this case, 
the validation results in a `chatter message`, not a blocking send-time error.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679

[2]:
https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#107348
Forward-Port-Of: odoo/enterprise#105763

When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error.

Steps to reproduce:
-------------------
* Install sales, inventory, subscription,
* Create a subscription product
* Create and validate a sale order with this product and a recurring plan
* Connect to Odoo with an user that only has inventory user right
* Validate the delivery -> Access Error

Observation:
-------------
When we validate the delivery,we call button_validate that will call [_action_done](https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_picking.py#L1427) 
During this we try retrieve invoices information [here](https://github.com/odoo/enterprise/commit/b07b1c47c97bb6d6da9fa61dacb5cba66aff2a16#diff-dbf7b40a6942fbcc81ebc4c3009a8a37a5a620cffac74889bd0ff2bccd52b1e3R30-R36).
The issue is that this user doesn't have access right to several records: 
* sol.order_id.invoice_ids  -> sale.order.invoice_ids 
* sol.order_id.last_invoice_date -> sale.subscription.plan

opw-5869446

Currently, an error occurs when the user opens the Partner Ledger report.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1nM6WZW0_knAoDZP0G3VZsv1RMxtY5ZEI/view)):**
 - Install the `Accounting` module.
 - Go to `Accounting Reports` (in developer mode).
 - Open the `Partner Ledger report`.
 - Go to `Options and disable Partners`.
 - Now navigate to `Reporting > Partner Reports > Partner Ledger`.

`KeyError: 'partner_ids'`

When the user disables the Partners filter, the partner_ids key is not included in the report options. Later, when the report is opened, the system tries to add amounts from move lines without a partner and, after [this commit], attempts to access partner_ids. Since partner_ids is not present, an error is raised [1]. similar error also occurs here [2].

This commit ensures that when filter_partner is disabled, opening the report works the same way as when no partner is selected by default.

[this commit]: https://github.com/odoo/enterprise/commit/2b429ec8b019df2983144dfd31193cfbd2cfd1ad

[1]- https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/account_reports/models/account_partner_ledger.py#L406

[2]- https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/account_reports/models/account_partner_ledger.py#L550

sentry-7138579048

Steps to produce:
---
- Install `sale_renting` and `contacts` modules.
- Go to contact and open `yourcompany` record.
- Add a new contact of type Delivery and save (leave the name empty).
- Go to Rental > New Order.
- Select YourCompany, Delivery as the customer.
- Add a rental product and confirm the order.
- Open the Schedule view.

Traceback:
---
`TypeError: sequence item 0: expected str instance, bool found`.

Root cause:
---
- At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence.

Solution:
---
- Use the partner's `display_name` instead of `name`. The `name` field
  can be `False` in some cases. The `display_name` field is a computed
  field that always provides a valid, formatted string by using fallback
  values such as the company name, parent name, or contact type. This
  ensures consistency and prevents errors

[1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61

opw-5914084
---

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

This commit is a backport of https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823 and https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424.

## Issue
When renewing a subscription, the tags and followers are not copied from the original subscription to the new one.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a confirm a subscription S
    - Any *Customer*
    - Any *Recurring Plan*
    - Any Product
    - In the *Other Info* tab, add a tag T
3. There should be two followers on the subscription S: the creator of the subscription, and the customer. If it is not the case, add at least one follower.
3. Create and confirm an invoice for subscription S
4. Back on the subscription S, click *Renew*
5. **The tag T is missing on the new subscription. Also, the followers were not copied from subscription S.**

## Cause & Fix

### Tags
In `SaleOrder._prepare_upsell_renew_order_values`, tags are not part of the `values` generated when renewing a subscription:

https://github.com/odoo/enterprise/blob/a650fb74fd79965a6f0e441e61d8977c599057e6/sale_subscription/models/sale_order.py#L1149-L1171

They were added by https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823:

https://github.com/odoo/enterprise/blob/245759ef82250a8eb32f38853e5c5f6aac841823/sale_subscription/models/sale_order.py#L1173-L1175

### Followers
Similarly to the tags, followers were not added/subscribed to the subscription when generating the renewed subscription. This was fixed by https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424, by creating and calling the `_subscribe_followers_to_new_order(order)` after creating the new subscription (`order`):

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L956-L958

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L2147-L2157

opw-5478071

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