The Knowledge article tree panel has been optimized to load articles, favorites, and access information in fewer steps. This should make navigating large Knowledge workspaces faster and smoother for users, especially when opening the side panel or the Knowledge home page.

This is done through successive commits.

The first one introduces a query counter test and then successive other commits
each improve this query counter up until the last one.

The various performances improvements include:
- Fetching all children articles that are going to be displayed all at once
- Batch compute user write access for the tree panel 
- Introduce '_parent_store' and 'parent_path' to speed up hierarchy operators
- Store the article active status on linked favorites
- Avoid checking root articles ACLs twice
- Avoid computing ACLs of the active article twice
- Avoid fetching favorited articles separately

This is best read by going through commits one by one instead of the full diff.
See underlying commits for details.

Task-2791000

Channel conversations now better distinguish regular messages from notifications. This makes discussions easier to read and helps users understand whether an item is part of the conversation or an informational update.

part of task-2918956

Community: https://github.com/odoo/odoo/pull/98262

Unread message counts in Odoo’s enterprise mail experience are now tracked at the conversation channel level rather than on the broader thread object. This makes the mail interface’s unread indicators more consistent and easier to maintain, with minimal direct impact on day-to-day users.

Community: odoo/odoo#98149
Part of task-2948676.

Studio approval rules can now assign a responsible person who is automatically notified through a next activity when approval is needed. This makes pending approvals easier to track and act on, while keeping activities synchronized when approvals are granted, refused, or completed.

Before this PR, it was impractical for a "manager" to know what
approval flows were waiting for them, leaving users to manually contact
their manager on a record asking for approval of the action. This made
the feature less useful in general.

This commit introduces the notion of a "responsible" on an approval rule
that will be notified that an approval is waiting for action via a next
activity that is "linked" to the approval (so granting or refusing the
approval will automatically remove the activity, and marking the
activity as done will automatically approve the action if it hasn't
been approved or rejected already).

To keep a clean link between approval rules, records and next activities
that pertain to them, a new model 'studio.approval.request' is
introduced which models such a link (indeed, since the rule has no entry
yet, there was no clean model on which to set this link and adding a
field on activities for that was not a good idea, as it would have too
wide an impact).

Task-2895596

(also fixed a display bug)

The Knowledge article form view and related tools have been rebuilt with a newer interface framework. This should make editing articles, moving content, and managing permissions more consistent and easier to maintain, while preserving the existing business workflow.

PURPOSE

Rewrite the form view and associated widgets using OWL.

SPECS

The following components have been re-written using OWL:
- Knowledge Form View (+ Renderer + Controller)
- The various Dialogs (MoveArticleDialog, ...)
- The permission panel

Task-2942515

This update keeps the Documents kanban view aligned with the latest interface styling changes. It removes a duplicated styling setting and adjusts the layout so the view continues to display correctly after the broader design refresh.

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

Requires: 
- https://github.com/odoo/odoo/pull/96195

task-2892062

Accounting users can now work without mandatory bank statements, while still creating and assigning statements when they need control checks. Statements can include end dates, ending balances, and scanned attachments, with warnings for missing statement coverage or balance mismatches.

First release, I'll fill the info later on

Task [#2879904](https://www.odoo.com/web#id=2879904&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form)

Related community PR: odoo/odoo#96128

New automated performance checks were added for key Knowledge navigation paths. These tests help monitor database usage when users open the Knowledge tree panel or main Knowledge menu, supporting future optimization work without changing user-facing behavior.

This commit simply introduces a query counter test for the tree panel knowledge
route. This will allow us to optimize that route in following commits.

While we are at it, we also add a quick query counter test for the
'action_home_page' method, as it is called every time the main Knowledge menu
is clicked.

Task-2791000

Corrects how Indian GSTR-1 and GSTR-3B reports calculate and display tax base values. This ensures nil-rated values appear correctly in GSTR-1 and prevents GSTR-3B from failing to open when it relies on those tax base calculations.

In GSTR-1 and GSTR-3B report if we domain_formula then label is balance but we have lable tax_base

So GSTR-1 nill rated not show value and GSTR-3B is not open because tax_base is use in aggregation formula

This fix prevents account reports from breaking when a column contains a value that is not a number. Instead of returning an invalid empty value that can disrupt page rendering, the report now uses a safe blank value so users see the report correctly.

When the column value is not a number, the default result should be an empty string and not None.

The value None makes the template bug because we try to concatenate classes.

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

This fixes an issue in financial reports where certain positive or negative sum calculations could incorrectly show as 0.0. Businesses using these report formulas will now see the intended values, improving accuracy in accounting reports.

The domain engine wasn't processing -sum_if_pos and -sum_if_neg correctly. It will always display 0.0 because it didn't recognize the subformula properly.

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

Global filter field matching now shows the actual pivot or list name instead of the underlying model name. This makes spreadsheet filters clearer for users and helps them choose the right data source with less confusion.

Before this commit, the name that was displayed in the Field Matching
section of global filters was the name of the model, not the name of
the pivot/list

Task-id 2960717

Users navigating journal item lists with keyboard arrows no longer encounter an error when focus reaches the table header. The system now skips attachment loading when no valid row cell is available, keeping accounting workflows uninterrupted.

…ew when using keynav

Reaching the table header when using the Up/Down arrows to navigate the journal item list view causes a stack trace due to the unavailability of a cell to focus.
In this case, we don't attempt to load to load an attachment

This change removes obsolete accounting report files and logic that were left behind after the same functionality was moved elsewhere. It reduces maintenance overhead and lowers the risk of confusion without changing expected reporting behavior for users.

search_template.xml should have been removed with https://github.com/odoo/enterprise/commit/f435654f70f3d6a1fec7fa696945f2c0eb9a7056
as it is now defined in report_templates.xml

The code in account_reports.py is already done with the init_options functions

Several enterprise apps were adjusted to stay compatible with an underlying service API update. This keeps features such as documents, spreadsheets, payroll dashboards, maps, and studio reports working reliably after the platform change.

This PR is the enterprise counter-part of odoo/odoo#99018
It adapts calls to the orm service w.r.t. its API changes.

The Project and Field Service apps have been updated to use Odoo’s newer interface framework, making screens such as task views, project sharing, guided tours, and right-side panels more consistent and maintainable. This is mainly an internal modernization that should preserve existing workflows while improving the foundation for future enhancements.

This commit migrates the custom code used in the Project App in OWL.
This commit:

- adapts the JS tour according to the OWL views
- remove the dead code
- adapts code of the project right side panel
- migrate the webclient for Project Sharing feature

task-2944742

The Barcode app and related manufacturing work order screens were modernized to use Odoo’s newer interface framework. This should make barcode workflows easier to maintain and includes small fixes that improve reliability when editing quantities and saving inventory adjustments.

Replace all legacy JS code with code using OWL.

task-2885757
subtask-2941622

Community PR: odoo/odoo/pull/97314

This update renames an internal setting that controls whether selection options are available in document lists. It does not change user-facing behavior, but makes the code easier to understand and maintain for future improvements.

Before this PR: In export invoices for l10n-cl, if the user tries to use the original customer vat number, or if it was empty, there is an error when Odoo creates the envelope in order to send the invoice to the customer. After this PR: For foreign customers, prevent the need to use 55555555-5 as the partner vat if the customer is a foreigner, also allowing to use its own original vat number, selecting the correct RUT for foreigners during the envelope creation. In this case, we evaluate

Before this PR:
In export invoices for l10n-cl, if the user tries to use the original customer vat number, or if it was empty, there is an error when Odoo creates the envelope in order to send the invoice to the customer.

After this PR:
For foreign customers, prevent the need to use 55555555-5 as the partner vat if the customer is a foreigner, also allowing to use its own original vat number, selecting the correct RUT for foreigners during the envelope creation.

In this case, we evaluate whether the partner is a foreign customer using the l10n_cl_taxpayer_type field, which must have the value '4'. This is because, if we evaluate if the client is foreign using only the country_id, we run the risk of preventing the possibility of creating a conventional ticket (boleta) if that client does not qualify (or does not need) an invoice (export invoice code 110).

Forward-Port-Of: odoo/enterprise#30096

…ith a form view With this commit, `See records` action on pivot cell now redirects to an action with both list and form view. Task-id 2941453 Forward-Port-Of: odoo/enterprise#30817 Forward-Port-Of: odoo/enterprise#30771

…ith a form view

With this commit, `See records` action on pivot cell now redirects to
an action with both list and form view.

Task-id 2941453

Forward-Port-Of: odoo/enterprise#30817
Forward-Port-Of: odoo/enterprise#30771

Side effect of commit [1]. With this commit, the goal was to allow SEPA credit transfers for Swiss companies instead of forcing the use of generic credit transfers. However, other situations were encountered were some payments were considered as SEPA while they should be generic instead. This commit should solve the 2 issues identified: 1/ for Swiss companies, all warnings were deactivated. We should remove that, as there is no real business need for this, and we now need to proper

Side effect of commit [1].

With this commit, the goal was to allow SEPA credit transfers for Swiss
companies instead of forcing the use of generic credit transfers.

However, other situations were encountered were some payments were
considered as SEPA while they should be generic instead. This commit
should solve the 2 issues identified:

1/ for Swiss companies, all warnings were deactivated. We should remove
that, as there is no real business need for this, and we now need to
properly detect SEPA and generic payments.

2/ for operations in currency other than EUR, we were not returning a
warning if the currency of the company was not EUR, which is often the
case for Swiss companies.

We should keep the existing intended behavior and not display useless
warning in case of Swiss companies, but we should do the filtering
outside of the function that computes the warnings to avoid side effects
as it is used elsewhere like in the function to compute the field
sct_generic.

[1]:https://github.com/odoo/enterprise/commit/f1b955609633f9c5debf36035425455a7fdb6ac3

opw-2961290

Forward-Port-Of: odoo/enterprise#30807
Forward-Port-Of: odoo/enterprise#30770