Belgian salary package forms now require notes when employees select hospital or ambulatory insurance for a spouse or other family beneficiaries. This helps payroll teams collect the identities needed to process these insurance benefits correctly and avoid incomplete benefit requests.

With this commit, hospital and ambulatory insurance notes are now required when the respective options are selected.

This is not implemented in a generic way, as it is only needed for Belgian payroll and salary benefits (as opposed to personal information) usually have sensible default values. In addition, the insurance fields are currently already handled with custom javascript.

task-3866298

Empty views now show helpful guidance directly from the view display area, making it easier for users to understand when there are no records and how to get started. Knowledge embedded views also benefit from this guidance, improving the first-use experience when content has not yet been added.

This PR will move the no-content helper from the view controllers to the view renderers and add a `o_empty` class on the renderer container when the no-content helper is shown allowing people to define new css rules.

task-3381729

Salary attachment reports now include every configured attachment type instead of only three predefined categories. This gives payroll teams a more complete view and reduces the need for manual follow-up when custom or additional attachment types are used.

After this commit, salary attachment reports will list all available salary attachment types and not the 3 hard coded ones that were previously available

task-3943424

The Bill of Materials overview now loads key information first instead of calculating every stock detail upfront. This makes the report much faster to open for complex products with many nested components, while detailed data is still available when users expand sections.

The BoM overview report loading time could be very long due to a lot of recursive
function calls (mainly stock related).

These calls could be limited to the information we want to display on the report
(basically the first layer of the bom), making the loading of the BoM overview lazy.

However, we still need to compute the price of the bom and components/sub-boms,
so loading the BoM overview will still go through all of them, but will not
take the stock part of the components/sub-boms into account, which was the most
time-consuming part of the loading.

Time gain speaking, this pr will loose some time when unfolding all at once
because it will recompute every bom data, but the time lost is significally lower than
the time gained at loading if the bom has a lot of sub-boms.

Displaying the time gained does not really make sense as it greatly depends on
the number of components/bom and the depth of the boms but we can almost approximate
the loading time to the time to load the components of the first BoM.

task-id: 3422605
community: https://github.com/odoo/odoo/pull/165635