This fix ensures customer follow-up financial fields are only available to users with the appropriate accounting permissions. It also tightens the underlying access checks and limits unnecessary data refreshes, reducing the risk of improper access while keeping follow-up information accurate.

All the fields on res.partner computed with _compute_for_followup
should have account.group_account_readonly or account.group_account_invoice
groups. _query_followup_level should check for account.move.line read rights
and the flush should not be on all fields.

This PR is a followup on https://github.com/odoo/enterprise/pull/26102 . 

opw-2811678

Odoo Sign now supports signer authentication through itsme for Belgian and Dutch companies. This adds a stronger, localized identity verification option for signing workflows, with usage charged through IAP credits.

Adds sign_itsme module that implements the integration of itsme with sign,
allowing signers to authenticate using their itsme account. This feature will
be available for belgian and dutch companies, as itsme only supports these
countries. This module also depends on a IAP module as we charge credits for
each itsme authentication.

task-2844609

Adds standard Balance Sheet and Profit and Loss reports for Slovenian accounting localization. This helps Slovenian companies produce key financial statements directly in Odoo using localized reporting structures.

Add balance sheet and profit and loss for Slovenian localization

Task-id: 2724396

Signed-off-by: Ruben Gomes <rugo@odoo.com>

This update makes VoIP call queue status checks much faster by avoiding unnecessary database and access checks. Users should see quicker loading when viewing records with queued call information, especially in databases with many leads and activities.

The domain part generated by `_linked_phone_call_domain`
```
[
    ('activity_id.res_id', 'in', <rec_ids>)
    ('activity_id.res_model_id', '=', <id>)
```
is highly inefficient.
The ORM will convert it into (threat each condition independently):
```
[
    ('activity_id', 'in', env['mail.activity']._search([('res_id', 'in', <rec_ids>)]))
    ('activity_id', 'in', env['mail.activity']._search([('res_model_id', '=', <id>)]))
```
And the `_search` (of `mail.activity`) is override
and doesn't return a Query object but directly the result
(and do extra stuff for security reason).

Because of these, both condition/_search load much more than
necessary and check the access on too many records.
By example, the second condition will fetch every activity id
link to the current model (and check access to each),
no matter the current records.

Performance Improvements:
-------------------------
Only with 15_000 leads and 5_000 activity link to them, to read
`has_call_in_queue` value of 10 records:
It took 72 ms before and it takes 5 ms now.

The manufacturing product lifecycle document board was updated to work with the newer interface framework. This helps keep the document view compatible and reliable as the broader system evolves, with little visible change for users.

See odoo/odoo#99769

The subscription pricing and date fields have been updated to use Odoo's newer interface framework. This keeps subscription workflows aligned with the sales app modernization and should improve long-term maintainability without changing core business behavior.

As part of the migration of the sale code to owl the subscription
code that is dependent will migrate also.

See odoo/odoo#96661 for more details.

The employee cost field has been renamed to employee hourly wage and moved into a shared module so it can be used beyond timesheets. This makes workforce cost information available consistently for planning, manufacturing, field service, and related reporting without duplicating the same data.

The field timesheet_cost defined on hr_employee in hr_timesheet would be
useful in other modules (eg planning and MRP) as well. Therefore with this
commit the field is moved into a separate module upon which
hr_timesheet, MRP and planning will ahve a dependency. In addition this
field is renamed to employee_hourly_wage, which is a more accurate and
neutral name for this field, as it will not only be used in timesheets.

task-2929518

Planning can now distinguish employees with flexible hours from those with fixed schedules. This improves allocated-hour calculations by respecting breaks and working calendars for fixed-schedule staff while keeping flexible shift handling for roles like nurses or waiters.

Before this commit, in Planning, the shift's allocated hours are
automatically calculated based on the working calendar of the resource
except if the shift lasts <24h.
It was implemented this way to accommodate the use-case of people with
flexible hours e.g. nurses, firefighters, waiters etc. And so if the
working calendar were takken into account, night shifts would result
in 0 allocated hours (which it's wrong for the people with a flexible
hours). The side effect of the current implementation is that allocated
hours are not "correctly" calculated for people working with fixed
hours (that is people who follows a working schedule) because if a
shift is created from 8 AM to 5 PM, the allocated would be 9 allocated
hours instead of the expected 8 hours according to the working schedule
set on the resource linked to the shift (In other words, the typical
"lunch break" isn't deducted from the calculation).

This commit adds a flexible hours boolean field on the
`resource.resource` and `hr.employee` models. When the field is True,
the allocated hours computed will not take into account the working
schedule of the resource even if the period of the shift is longer than
one day, however, the max allocated hours are the hours_per_day set on
the working schedule set on the company set on the shift.
When the flexible hours is False than the allocated hours
computed will take into account the working schedule of the resource
linked to the shift or the one set on company set on the shift if no
resource and it is longer than one day.

task-2971572

This update improves the Master Production Schedule by making product and bill of materials selection more accurate, adding easier access from product and BOM screens, and enabling bulk actions on selected schedule lines. It also improves filtering, weekly date display, replenishment suggestions, and purchasing deadline visibility so planners can work faster with fewer mistakes.

List views have been visually refined and their styling simplified to provide a more consistent experience across Odoo. Column selection menus and editable list links were adjusted to avoid display issues and improve usability.

This merge simplifies and uniformize the ListView's styling.

Part of the overall v16 SCSS optimization/restyle, task-2704984.

task-2946835

A test-only spreadsheet patch was relocated so its setup and cleanup now live in the same module. This keeps spreadsheet-related tests organized and avoids accidental dependencies from affecting other document spreadsheet tests.

disable_patch has been introduce in tests assets in order to disable the graph_spreadsheet, as this patch add dependencies (as menu) to the graph view.

In https://github.com/odoo/enterprise/commit/2cd6bd81051bb064a5f7d5f8d08bfdee4afce76d, the patch has been moved to spreadsheet_edition, but the unpatch was still in documents_spreadsheet.

The CRM pipeline dashboard could fail to open because required start and end date fields were not included in the view data. This fix ensures cohort views automatically include those date fields, preventing the dashboard error and restoring access to reporting.

This follows revision
odoo/odoo@4636620004f0cc0e504cd6694fe8ddb6758ba811

When accessing the dashboard view in
CRM -> Reporting -> Pipeline
an exception occurred:

```
UncaughtPromiseError > TypeError

Uncaught Promise > fields[dateStop] is undefined
```

This is because the field in the cohort node attributes `date_start` and `date_stop` were not added automatically to the available fields of the view,
hence these fields were not passed in the fields returned by `get_views`, because of the above mentioned revision.

A similar code exists in `base` for the calendar view: https://github.com/odoo/odoo/blob/3a2196d73cfe5b5cd6cfda8e203b81969106831e/odoo/addons/base/models/ir_ui_view.py#L1157-L1160

Related to odoo/odoo#100021

The cohort reporting view now reads hidden-field settings from the updated data format sent by the server. This prevents fields that should be hidden from being shown or handled incorrectly after a related platform change.

This commit is the counter part of https://github.com/odoo/odoo/pull/99948

It adapts the cohort view to make it retrieve the `invisible`
information on `<field/>` nodes inside the `modifiers` attribute,
since the server no longer sends the `invisible` attribute, since
https://github.com/odoo/odoo/pull/99619.

Portal users can now continue opening items in their favourite Knowledge article list after adding or removing a favourite. This fixes a navigation problem so eligible users can keep accessing shared knowledge content without the list becoming unusable.

Currently, in the knowledge module, when a portal user adds/removes an article
to their favorite list, the whole list is unclickable.

To fix the issue, we have added `portal_readonly_mode` param in the template
render according to the user rights and it will show a clickable link if the
user has correct rights.

task-2925871

This fix updates styling rules so appraisal and enterprise form fields display correctly after recent interface changes. It helps maintain a consistent, polished layout for users working with appraisal forms and other enterprise views.

task-2898432

This update fixes small typos in the SEPA direct debit mandate interface. It improves clarity for users reviewing or managing direct debit mandates without changing any business process or functionality.

Signed-off-by: maximilien(malb) <malb@odoo.com>

This fixes a Planning display issue where shifts for an employee could overlap with open shifts in the Gantt view after that employee was archived. Schedules now show the correct end date, helping managers read past and current planning information accurately.

Before this commit, in planning when a shift is made for any user and in between the user is archived the shift in Gantt view overlaps with open shift even when the user is archived

After this commit, the shift doesn't overlap in Gantt view when user is archived

task-2969228

The accounting spreadsheet dashboards have been relocated into the accountant-focused app so they align better with where accounting users work. This is an internal organization change that should preserve the existing dashboard experience while improving module structure and ownership.

…tant

Purpose ======= A prefilled value with '0' as result will be considered as unset, as jQuery $(elem).val() returns an empty string instead of '0'. Forward-Port-Of: odoo/enterprise#31227

Purpose
=======

A prefilled value with '0' as result will be considered as unset, as jQuery $(elem).val() returns an empty string instead of '0'.

Forward-Port-Of: odoo/enterprise#31227

Remove the border of the feedback templates in the hr_appraisal settings. task-2930635 Forward-Port-Of: odoo/enterprise#31117 Forward-Port-Of: odoo/enterprise#30140

Remove the border of the feedback templates in the hr_appraisal settings.

task-2930635

Forward-Port-Of: odoo/enterprise#31117
Forward-Port-Of: odoo/enterprise#30140

…g paused Before this commit, the MRR of a sale order in the category paused invoicing would be equal to 0. This was an error as we want to keep the subscription alive during this period. Forward-Port-Of: odoo/enterprise#31175

…g paused

Before this commit, the MRR of a sale order in the category paused invoicing would be  equal to 0. This was an error as we want to keep the subscription alive during this period.

Forward-Port-Of: odoo/enterprise#31175

Reported via p/feedback Forward-Port-Of: odoo/enterprise#31132

Reported via p/feedback

Forward-Port-Of: odoo/enterprise#31132

The line "Provisions pour risques et charges: dotations" should include the accounts from 635 up to 638 instead of 637. This PR fixes this. Forward-Port-Of: odoo/enterprise#31204 Forward-Port-Of: odoo/enterprise#30426

The line "Provisions pour risques et charges: dotations" should include the accounts from 635 up to 638 instead of 637.

This PR fixes this.

Forward-Port-Of: odoo/enterprise#31204
Forward-Port-Of: odoo/enterprise#30426