Project Gantt views now show an empty line for assignees who have planned open tasks across the whole view, not just the next period. This makes team planning clearer by keeping relevant assignees visible whenever their scheduled work exists in the project.

In the project.task gantt view, an empty line is displayed for assignees to a planned and opened task, but only for the next period. Ideally, if a planned and opened task exists in the project, it would be better to have an empty line displayed for its assignees in the whole gantt view, not only for the next period.

This PR will change the group expand's domain to include tasks that have a planned_date_begin and planned_date_end set, thus including assignees who have planned tasks.

task-3414550

Invoice-related automation was updated to use the newer way of setting default currency values after an older internal method was removed. This keeps invoice extraction, bill prediction, and document workflows aligned with the latest accounting behavior and helps prevent failures in those processes.

Task [2197490](https://www.odoo.com/web?#id=2197490&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720)
The method doesn't exist anymore and has been replaced by a default_get

Related PR: https://github.com/odoo/odoo/pull/46522

Deactivating a restaurant table now archives its linked booking resource instead of deleting it. This prevents related appointment information from being lost and helps keep booking records consistent.

Previously when a table was deactivated the linked appointment resource was deteted. Since the appointment ressource is linked to other records, the appoitment ressource needs to be archived and not deleted.

Task-3432024

This fixes a demo data setup issue so the default account is assigned to the intended Belgian partner company instead of the main company. It helps ensure the Belgian-US consolidation demo starts with the correct accounting configuration when installed.

The default account should have been set on be_partner, not main_company
(as default at install time)

This update replaces an older screen-blocking component with Odoo’s newer interface service in payment and VoIP areas. Business users should see the same workflows with a more maintainable foundation, plus the call pop-up can now be closed directly from its title bar.

Several enterprise apps were updated to align with a platform cleanup that removes a shared web asset bundle. This keeps the affected areas compatible with the latest Odoo web framework changes without changing day-to-day business functionality.

*: account_followup, documents, knowledge, pos_preparation_display,
project_enterprise, sign, web_enterprise, web_gantt, website_sale_ups

This commit adapts the enterprise modules to the removal of the assets
common.

https://github.com/odoo/odoo/pull/132190

## Issue When grouping by 2 factors, in some circumstances, the total allocated hours for the group is not equal the sum of the allocated hours of all the pills in said group. This happens when we have an open shift which happens to have some part of it's shift outside the company working hours, which shouldn't be the case, as open shifts are 24/24. ## Steps to reproduce - Install Planning - Planning > Group by Role then Resource - Choose an open shift, and set the end time to 20h - Noti

## Issue
When grouping by 2 factors, in some circumstances, the total allocated hours for the group is not equal the sum of the allocated hours of all the pills in said group. This happens when we have an open shift which happens to have some part of it's shift outside the company working hours, which shouldn't be the case, as open shifts are 24/24.

## Steps to reproduce
- Install Planning
- Planning > Group by Role then Resource
- Choose an open shift, and set the end time to 20h
- Notice the aggregate of the allocation hours for the group is not correct.

## Cause
There is an inconsistency of the allocated hours of the record, and what is computed as alloc.hours on the pill after it had been enriched. The main condition which split the computation between if we take the calendar into question, or not, `isFlexibleHours`, returns `undefined` when the `resource_id` is `false`, which is the case for open shifts, as they have no resource assigned to them. This leads to the condition to be evaluated falsy, taking the code path where the calendar is taken into account.

## Fix
This patch introduces multiple small corrections:
- Explicit casting to boolean for the return value of `isFlexibleHours`, to correct the signature return value.
- Add an additional condition specifically for open shifts, they should take the same code path as shifts which resource is a flexible resource.
- Do not multiply twice the allocated hours with the alloc.%, it's already taken into account in the allocated hours of the record.

## Affected versions
saas-16.2 up to master

## Reference
opw-3438537

Forward-Port-Of: odoo/enterprise#46132

Since the redesign of the WebClient (Milk), the icon size was changed, but not in the Web Manifest. This commit changes these values. Note: Old size: 140x140 New size: 100x100 Forward-Port-Of: odoo/enterprise#46189

Since the redesign of the WebClient (Milk), the icon size was changed, but not in the Web Manifest.

This commit changes these values.

Note:
Old size: 140x140
New size: 100x100

Forward-Port-Of: odoo/enterprise#46189

When the `test_auto_send_for_digitization` is ran at around midnight, it could happen that it failed because of the expense `date` not being set to the expected value. This was due to the fact that we rely on the `create_date` and `date` to decide if the date should be filled or not. Unfortunately, when `date` is set to "now" there can be a few seconds of difference with the `create_date` leading to a mismatch when one is set before midnight and the other after midnight. The test will n

When the `test_auto_send_for_digitization` is ran at around midnight, it could happen that it failed because of the expense `date` not being set to the expected value.

This was due to the fact that we rely on the `create_date` and `date` to decide if the date should be filled or not.

Unfortunately, when `date` is set to "now" there can be a few seconds of difference with the `create_date` leading to a mismatch when one is set before midnight and the other after midnight.

The test will now force that `date` is set to exactly `create_date`.

This is very similar to #41141.

Forward-Port-Of: odoo/enterprise#45993

This PR bundles some urgent small fixes to the new MRP Shop Floor display. Please refer to the individual commits for details. Task: 3456817 Forward-Port-Of: odoo/enterprise#45907

This PR bundles some urgent small fixes to the new MRP Shop Floor display.
Please refer to the individual commits for details.

Task: 3456817

Forward-Port-Of: odoo/enterprise#45907

When someone opens an article in Knowledge, we would like to automatically focus the editor, allowing people to start typing without the need to click. The cursor will help users understand that the document is editable. This commit will ensure that the editor of Knowledge will automatically be focused when opening an article. task-3416522 Forward-Port-Of: odoo/enterprise#44605

When someone opens an article in Knowledge, we would like to automatically focus the editor, allowing people to start typing without the need to click. The cursor will help users understand that the document is editable.

This commit will ensure that the editor of Knowledge will automatically be focused when opening an article.

task-3416522

Forward-Port-Of: odoo/enterprise#44605

Before this commit, some menuitems for reporting in recruitment were not set properly leading to a translation issue. Forward-Port-Of: odoo/enterprise#46083

Before this commit, some menuitems for reporting in recruitment were not set properly leading to a translation issue.

Forward-Port-Of: odoo/enterprise#46083

Steps to reproduce: 1. set up `l10n_de_pos_cert` and make a PoS in German company 2. make an order, make the payment and validate 3. add another order line, do not pay it and close the session 4. re-open the session, the PoS will never load A tax error is raised and blocks the PoS from loading. The issue happens because when checking for valid VAT rates, `vatRateMapping` variable is not initialized. To fix this initialization of orders from local storage should await the result of `vat

Steps to reproduce:
1. set up `l10n_de_pos_cert` and make a PoS in German company
2. make an order, make the payment and validate
3. add another order line, do not pay it and close the session
4. re-open the session, the PoS will never load

A tax error is raised and blocks the PoS from loading.

The issue happens because when checking for valid VAT rates, `vatRateMapping` variable is not initialized. To fix this initialization of orders from local storage should await the result of `vatRateMapping` from fiskaly so the check can work.

opw-3439224

Forward-Port-Of: odoo/enterprise#45731
Forward-Port-Of: odoo/enterprise#45449

…for the car In the salary configurator task-3302341 Forward-Port-Of: odoo/enterprise#46176 Forward-Port-Of: odoo/enterprise#42531

…for the car
In the salary configurator
task-3302341

Forward-Port-Of: odoo/enterprise#46176
Forward-Port-Of: odoo/enterprise#42531

When neutralizing the database we should disable existing bank connections opw-2758998 Forward-Port-Of: odoo/enterprise#45962

When neutralizing the database we should disable existing bank connections

opw-2758998

Forward-Port-Of: odoo/enterprise#45962