Gantt timeline items now use simpler, consistent rounding when displaying time blocks. This makes planning views easier to read and removes special-case behavior that could make schedule pills appear inconsistent.

This commit removes the weird logic behind gantt pill rounding and simplifies it to always round a timeframe up. This allows to also remove the logic behind the planning gantt renderer to take into account special cases of pill rounding.

Task-2223818

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

Bank synchronization setup now creates a new journal by default, helping keep newly connected bank feeds clearly separated. The existing dashboard Configure flow keeps its previous behavior, reducing disruption for users managing current journals.

Except when coming from the Configure button on the dashboard
Community: https://github.com/odoo/odoo/pull/37152

Task planning fields now use the clearer label "Allocated Time" instead of "Planned Hours" across project, field service, timesheet, and sales timesheet areas. This reduces confusion for users by aligning terminology wherever task time allocation is shown or reported.

**= project_timesheet_forecast,project_timesheet_enterprise. Before this commit 'project.task' model 'planned_hours' field is inconsistent to the 'allocated_hours' field.

After this commit rename the 'planned_hours' to 'allocated_hours' and related string change to 'Allocated Time'.

task-3231680

Invoice extraction can now recognize whether a scanned document is a standard invoice or a credit note by looking for “credit note” wording and translations in OCR results. This helps classify documents more accurately and reduces manual correction during invoice processing.

By checking the presence of the phrase "credit note" or its translations in the OCR results, we can now identify the type of invoices.

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 update makes Knowledge automation more dependable when interacting with forms, chatter, attachments, and editable description fields. It reduces failures caused by translated labels, read-only forms, dialogs, timing issues, and changing page layouts, helping users apply Knowledge macros more consistently across business records.

### Batch of fixes coming from 16.0 and 16.3

- Stop relying on translated attributes from discuss components for Knowledge
  macros selectors and use classes instead.
- Prevent registering fields for Knowledge macro from Form views inside a dialog
  (modal).
- Use the notebook page `name` attribute instead of `string` to switch tabs in a
  Form view, since the `string` is translated. After this fix, an html_field in
  an unnamed notebook page won't be considered for Knowledge macros and the
  buttons won't appear.
- Don't allow macros to click multiple times on the same element during a
  trigger step. This could be an issue if the macro steps advance faster than
  the time it takes for a component to re-render after it's state changed
  because of the click (i.e. for a toggle, the macro could toggle again and
  return to the original state, resulting in the rendering being aborted).
- Ensure that the macro "use as description" searches for an editable version of
  the `html_field` (if it finds a non-editable version, it should try and switch
  to a notebook tab to find the editable version).
- Fix a semantic typo in Knowledge service (`xmlDoc` property was misnamed
  `fieldInfo`).
- Remove unnecessary unregistration of the current commandsRecordInfo (the
  explanation in the comment is wrong as controllers get an unique `jsId` for
  each instance, even for the same controller concern the same view called later
  in the breadcrumbs sequence.
- Don't register html fields for a Knowledge macro if their form view is in
  readonly mode or equivalent (non-editable).
- Remove usage of `interval` macro property as it is obsolete since [1].
  It is replaced by `{ defaultCheckDelay: 16 }` for the MacroEngine (16 ms
  between each step of a Macro).

[1]: https://github.com/odoo/odoo/commit/3a798039d6f200f8e28448ddb6a2d3c46654a203

### Macros refactoring (16.5+)

Keep only one form controller patch in Knowledge.

Refine the way the chatter and html form fields are detected for Knowledge
macros:
- Instead of updating the `commandsRecordInfo` at every patch if the record's id
  changed, it can be done as an `onWillUnMount` hook, since we only care about
  the last visited record of the form view.
- Use a `CallbackRecorder` to accurately ask the `Chatter` whether the current
  user is able to send messages or attach files, instead of relying only on the
  presence of the chatter in the `xmlDoc`.
- Add/Move some functions related to registering/discarding/validating a
  `commandsRecordInfo` in the `KnowledgeCommandsService` to limit the amount of
  functions added in the `FormController`.

Use action service to restore the form view instead of clicking on the
breadcrumbs in the DOM. Breadcrumbs are only checked to ensure that the
current view has a breadcrumbs history. This is more robust against future
designs of the breadcrumbs (where not every element of the breadcrumbs list is
displayed directly as a link (some of them can be hidden in a popper).

Add comments to better explain the macro processes and the
`KnowledgeCommandsService`.

Add a timeout of 10 seconds for macros, to give back control to the user if a
macro is stalled.

Knowledge macros rely on the name attribute of a notebook page to switch
between tabs in a Form notebook. That attribute is not mandatory, so some views
with a valid html_field did not have one. This commit add the name attribute
so those fields can now be manipulated by Knowledge macros.

See `searchInXmlDocNotebookTab` in `abstract_macro.js` for more details about
the usage of the `name` attribute in Knowledge macros.


task-3410128

Forward-Port-Of: odoo/enterprise#45672
Forward-Port-Of: odoo/enterprise#45128

Fixes an issue where related items in Sign template editing, such as tags and selection options, were not displayed properly after a recent model change. This helps users configure signing templates reliably without missing or incorrect field choices.

After https://github.com/odoo/enterprise/pull/43125 was merged, the x2many records that are rendered in the sign template edition are not being shown properly (e.g. tags in the top bar, selection options in the popover of a selection field). This commit fixes these issues by changing how we set the dependent fields of fields that use the relational model.

task-3455387

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