This update aligns Belgian payroll and salary holiday demo data with the newer leave type color field. It helps keep sample and test data compatible with the latest HR leave setup, reducing maintenance issues without changing day-to-day user workflows.

As part of https://github.com/odoo/odoo/pull/99804, the color_name field is remove from the hr.leave.type model and replaced by color.
This commit removes color_name from the demo data.

task-2963752
_

Payroll holiday attests now include a gross pay amount, giving Belgian payroll teams clearer salary information when preparing employee departure documents. This improves the completeness of holiday attest reporting and helps reduce manual lookup or calculation work.

TaskID: 2984604

This fixes an issue in Planning where a repeat end date could remain set even when the repeat option was no longer configured to end on a specific date. It helps prevent misleading scheduling information and keeps recurring planning entries consistent with the selected repeat settings.

repeat_until should be set to False when repeat_type is != 'until'

Task-3041205

The Sign app now loads a supporting page-capture component only when it is actually needed. This keeps the initial signing experience lighter while preserving the same signing functionality for users.

lazyload html2canvas for sign following the exemple of odoo/odoo#102376

Improves the style of the badges for 'renewed' and 'closed' in the sale.order form view. task-3010781 Forward-Port-Of: odoo/enterprise#32492

Improves the style of the badges for 'renewed' and 'closed' in the sale.order form view.

task-3010781

Forward-Port-Of: odoo/enterprise#32492

When generating the general ledger and exporting it in the XAF format, a MemoryError could occur because of the sheer number of rows that the get_vals_dict query produced. This was mostly because of the LEFT JOINs on res_partner_bank and res_bank that led to lots of duplicated rows with the same move_line_id, move_id, journal_id, tax_id, partner_id, account_id. Because we functionnaly only need one res_partner_bank for each partner_id, this commit replaces the two LEFT JOINs with a single LEF

When generating the general ledger and exporting it in the XAF format, a MemoryError could occur because of the sheer number of rows that the get_vals_dict query produced. This was mostly because of the LEFT JOINs on res_partner_bank and res_bank that led to lots of duplicated rows with the same move_line_id, move_id, journal_id, tax_id, partner_id, account_id.

Because we functionnaly only need one res_partner_bank for each partner_id, this commit replaces the two LEFT JOINs with a single LEFT JOIN on a CTE. There is a DISTINCT ON (partner_id, company_id) inside this CTE so that the resulting set only contains one row for each (partner_id, company_id) pair. That way we ensure that the LEFT JOIN will only produce one row by account_move_line.

This does not only fix a possible MemoryError getting raised, it also fixes a performance edge case with a small date range of account_move_line.date. Briefly, before this patch, a small date range on a big database could lead postgres to wrongly plan the joins order thanks to a skewed output rows estimate. Because of that postgres produced way too many rows after all the JOINs. This lead to the sort algorithm being an external sort (sort on disk) instead of an in-memory merge sort as sorting in-memory would overflow the work_mem. This made the whole query around [40 times slower](https://explain.dalibo.com/plan/a16d9e5347dg27d7#plan/node/4) for small (1-week) date ranges (cf. [year range](https://explain.dalibo.com/plan/c792354g297afe09#plan) for comparison).

Forward-Port-Of: odoo/enterprise#33136
Forward-Port-Of: odoo/enterprise#32903

[IMP] l10n_lu_reports: use account_codes in formulas bypass a formula bug disallowing opening of the report (not fixing the bug). Also, the use of a domain engine instead of account_codes was improper in those circumstances => This bug is fixed in https://github.com/odoo/odoo/pull/103755 [FIX] l10n_ch_reports: fix bad formula & id fix bad aggregation formula and expression ids making impossible the opening of the report Signed-off-by: Julien Alardot (jual) <jual@odoo.com> Forw

[IMP] l10n_lu_reports: use account_codes in formulas

bypass a formula bug disallowing opening of
the report (not fixing the bug). Also, the use
of a domain engine instead of account_codes
 was improper in those circumstances
=> This bug is fixed in https://github.com/odoo/odoo/pull/103755

[FIX] l10n_ch_reports: fix bad formula & id

fix bad aggregation formula and expression ids
making impossible the opening of the report

Signed-off-by: Julien Alardot (jual) <jual@odoo.com>

Forward-Port-Of: odoo/enterprise#33038

[FIX] white space on the right of the bank rec widget on large screens (Thanks to @adr-odoo ) [FIX] Amount field in manual operations misplaced [FIX] The selected line on top list should have a shadow not an outline [FIX] Fix dark mode colors [FIX] The gap between the border of kanban cards and right div (thanks to @dylankiss) Forward-Port-Of: odoo/enterprise#32732

[FIX] white space on the right of the bank rec widget on large screens (Thanks to @adr-odoo )
[FIX] Amount field in manual operations misplaced
[FIX] The selected line on top list should have a shadow not an outline [FIX] Fix dark mode colors
[FIX] The gap between the border of kanban cards and right div (thanks to @dylankiss)

Forward-Port-Of: odoo/enterprise#32732

By clicking on the checkbox in the list view, the selection occurs twice due to the checkbox one not stopping the propagation effectively calling the select function twice making it select and unselect the item directly. TaskId-3040425 Forward-Port-Of: odoo/enterprise#33123

By clicking on the checkbox in the list view, the selection occurs twice due to the checkbox one not stopping the propagation effectively calling the select function twice making it select and unselect the item directly.

TaskId-3040425

Forward-Port-Of: odoo/enterprise#33123

Due to our inability to update the iOS app (following review from Apple), this commit aims at workingaround this limitation by avoiding to wait for a Promise that is never resolved in the iOS app. Steps to reproduce: - Setup Odoo with hr & documents installed - Open it with the iOS mobile app - In the BurgerMenu, open "My Profile" - In the stat buttons, click/tap on "x Documents" => the whole view hangs Note: this commit also replicates a comment from legacy codebase explaining why the

Due to our inability to update the iOS app (following review from Apple), this commit aims at workingaround this limitation by avoiding to wait for a Promise that is never resolved in the iOS app.

Steps to reproduce:
- Setup Odoo with hr & documents installed
- Open it with the iOS mobile app
- In the BurgerMenu, open "My Profile"
- In the stat buttons, click/tap on "x Documents" => the whole view hangs

Note: this commit also replicates a comment from legacy codebase explaining why the Promise returned by `downloadFile()` is voluntarily not awaited.

Forward-Port-Of: odoo/enterprise#33109
Forward-Port-Of: odoo/enterprise#33041

issue: Suppose employee A does not have a planning-based timesheet, but project and task based empty rows appear in all timesheets. Because its searches according to the current user's employee In this commit project and task based empty rows appear in my timesheet only not All timesheets. Because the specification of the task-2859663 Reproduction steps: - Install project_timesheet_forecast - Open Planning App - Create a planning slot - Generate the timesheet - Open the timesh

issue:
Suppose employee A does not have a planning-based timesheet, but project and task based
empty rows appear in all timesheets. Because its searches according to the current user's employee

In this commit
project and task based empty rows appear in my timesheet only not All timesheets. Because
the specification of the task-2859663


Reproduction steps:
- Install project_timesheet_forecast
- Open Planning App
- Create a planning slot
- Generate the timesheet
- Open the timesheet App > All timesheet
- Search the  timesheet of any employee

task-2955983

Forward-Port-Of: odoo/enterprise#31140

See the explanation here: https://github.com/odoo/odoo/blob/5069c8fd1cee063827873de0f6c2d9fe938337a9/odoo/addons/base/models/ir_ui_view.py#L1209-L1217 The strategy was to create a temporary <t groups="..."> node which gets deleted after the postprocessing. The deletion counted on the fact `groups` was the only attribute set to delete this temporary technical node. In case someone configured manually in a view architecture directly a t node with a groups and something else. But, studio a

See the explanation here:
https://github.com/odoo/odoo/blob/5069c8fd1cee063827873de0f6c2d9fe938337a9/odoo/addons/base/models/ir_ui_view.py#L1209-L1217

The strategy was to create a temporary
<t groups="..."> node which gets deleted after the postprocessing. The deletion counted on the fact `groups` was the only attribute set to delete this temporary technical node. In case
someone configured manually in a view architecture directly a t node with a groups and something else.

But, studio adds another attribute to nodes with "groups=" in the context of the studio edition (`studio=True` in the context) https://github.com/odoo/enterprise/blob/7e66f89e1c85852908edc45e72706e51838960b0/web_studio/models/ir_ui_view.py#L53 and therefore another attribute was added on this temporary technical node, which therefore didn't get deleted properly before being send to the webclient.

So, we change the heuristic, instead of relying no the fact `groups` was the only attribute, set a technical attribute on the node to identify it comes directly from the postprocessing and it must be deleted properly before being sent to the webclient.

Forward-Port-Of: odoo/enterprise#33075

In the **Master Plan Schedule**, when the mouse pointer enter or leave the main "REPLENISH" button or the row-specific "REPLENISH" link, it triggers an event that fetch elements of the row(s) based on a specific class attribute. However, some row(s) of the MPS don't have any element that refer this specific class and so, trying to access the first index of the fetched result throw a `TypeError: cannot read properties of null`. Task: 2985735 Forward-Port-Of: odoo/enterprise#32893

In the **Master Plan Schedule**, when the mouse pointer enter or leave the main "REPLENISH" button or the row-specific "REPLENISH" link, it triggers an event that fetch elements of the row(s) based on a specific class attribute. 
However, some row(s) of the MPS don't have any element that refer this specific class and so, trying to access the first index of the fetched result throw a `TypeError: cannot read properties of null`.
Task: 2985735

Forward-Port-Of: odoo/enterprise#32893

Forward-Port-Of: odoo/enterprise#33034

Forward-Port-Of: odoo/enterprise#33034

Currently, when creating a social post, the focus of the form view is automatically put into the "Campaign" field. This is slightly annoying as one would prefer having the focus in the "Message" field instead, this commit changes that. Task-3029690 Forward-Port-Of: odoo/enterprise#32876

Currently, when creating a social post, the focus of the form view is automatically put into the "Campaign" field.

This is slightly annoying as one would prefer having the focus in the "Message" field instead, this commit changes that.

Task-3029690

Forward-Port-Of: odoo/enterprise#32876