Helpdesk teams now open their tickets in a clearer list grouped by stage, making it easier to review workload. Configuration screens were simplified by removing unnecessary links and warnings, while stage setup now requires linked teams to keep helpdesk organization consistent.

Purpose of this commit to improve the generic usage of helpdesk app.

So in this commit done the following improvements,

- open tickets for the particular team from the dashboard it will open the
  group by stage in the 'list' view.
- remove the internal link for the 'ticket_type_id' field.
- 'team_ids' field make required.
- remove the warning from the module fields and make the page reload when
saving the record.

task-3186603

The Swedish reporting tests were updated to match the latest tax and account naming taxonomy. This helps keep report validation reliable as naming conventions change, reducing the risk of false test failures without changing business workflows.

As the taxes name change with the new taxonomy, the tests must be slightly adapted to continue to use the same taxes

Task-3052677
Task-3122530

The message shown to read-only users viewing restricted, unpublished knowledge articles has been reworded. This makes the article access status easier to understand by explaining that the article is not published and only specific people can access it.

This commit rewords the div added by the website_knowledge module inside the PermissionPanel.

It now says :
'Article not Published
Only specific people can access'

This is changed for users that can only read the article with no editing rights

task-3290824

The asset report now shows draft assets when users choose to include draft entries. This gives finance teams a fuller view of planned depreciation, while only adding draft assets that already have related draft accounting entries.

- Update the asset report's _query_values function to display draft assets when the user selects the "include draft entries" option
- Ensure draft assets are included in the report only if they have associated draft account entries, for a more comprehensive overview of all assets and their depreciation

Task-Id: 3229921

The Approvals app now introduces a dedicated component for handling approval acceptance actions. This makes the approval experience more consistent and easier to maintain, helping users process approval requests more reliably.

Task-2579306

The Approvals app now has a reusable approval component and supporting model changes. This should make approval-related screens more consistent and easier to improve over time, with limited immediate impact for end users.

Task-2579306

Mail notifications are now handled through a dedicated notification component, making the notification area easier to maintain and evolve. This should support a more consistent user experience in Enterprise messaging without changing the overall workflow for users.

Task-2833579

community: https://github.com/odoo/odoo/pull/89746

The Approvals app now introduces a clearer refusal action within approval activities. This helps users handle approval requests more directly and consistently, improving day-to-day workflow efficiency.

Task-2579306

This change updates an internal Discuss Enterprise performance test to account for an additional check of link preview status. It keeps automated quality checks aligned with current behavior, with no expected direct impact for end users.

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

Dark mode button styling has been refined so secondary buttons are easier to distinguish from page backgrounds. Hover and active states now use brighter, more consistent colors, improving readability and usability across affected Odoo screens.

This PR introduces some minor changes to the dark mode buttons color.


Previously, there was an issue with secondary buttons
having a `$o-gray-200` background in light mode which is equal to
`$o-view-background-color` in dark mode, so we couldn't distinguish
buttons over the background.

The methode used in this commit is to lighten a `$o-gray-*` variable
to keep it consistent with our existing grayscale.

There is also an improvement on the `hover` and `active` state of these
secondary buttons. We were previously using `$o-white` as the background
which becomes `$o-black`in dark mode.

We now use a dark green color mixed with the action-color
to get something lighter and brighter.

The Discuss-related components in Odoo Enterprise were adjusted to rely on fewer external dependencies and to load shared messaging components more directly. This helps simplify maintenance and can improve reliability for features that integrate with discussions, such as Approvals, Documents, Sign, and VoIP.

Task-2967711

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

The schedule shortcut now uses the record currently being viewed instead of carrying over a record reference from a previous screen. This prevents users from opening or acting on the wrong manufacturing planning schedule when navigating between related records.

Before this commit, the context added to the schedule stat button contained a reference to the active_id value. However, in this case, we actually want the current id of the record that we are looking at, not the id from a previous view.

Note that as far as I can tell, almost every use of `active_id` in stat button is wrong. It just usually works because we don't have an active id set, and there is a fallback in the basicmodel to get the current record id instead.  However, if a user would get to that form view by following some other relations and coming from another form view, then the active_id would not be correct.

This update reorganizes how the system temporarily blocks user actions during processing, making that capability available through a shared service. It supports the ongoing modernization of the web interface and helps reduce internal dependencies, improving maintainability across several business apps.

Task-Id 2183810

This pull request updates the underlying messaging and discussion components used across several Odoo apps, including accounting, invoice processing, and approvals. The changes appear focused on refactoring and consistency, helping maintain the platform without introducing major user-facing changes.

This update modernizes the underlying discussion and activity features used in several Odoo apps, helping keep communication panels, approvals, documents, VoIP, calendar, and signing flows consistent and reliable. It also includes targeted fixes and test updates for areas such as CRM, mobile document activity menus, and bank reconciliation.

This update reorganizes and simplifies internal files that support messaging, approvals, knowledge, signing, and related business workflows. It should make future maintenance easier for developers without changing day-to-day user behavior.

Task-3057085

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

This update restructures internal messaging-related code used across approvals, accounting, invoice extraction, knowledge, and helpdesk areas. It also includes fixes to keep live chat and helpdesk knowledge flows stable while related interface changes are being rolled out.

Edit company contact address with Zip Code 31830 (CHH state) Issue an invoice PAC will fail to sign the CFDI with error """ Code : 401 Message : Fecha y hora de generación fuera de rango """ Correct timezone for TIEMPO_DEL_NOROESTE_ZIPCODES is America/Ciudad_Juarez available in latest revision of pytz package (pytz-2022.7.1) So use a similar timezone: America/Boise opw-3158554 Forward-Port-Of: odoo/enterprise#38881

Edit company contact address with Zip Code 31830 (CHH state) Issue an invoice

PAC will fail to sign the CFDI with error
"""
Code : 401
Message : Fecha y hora de generación fuera de rango """

Correct timezone for TIEMPO_DEL_NOROESTE_ZIPCODES is America/Ciudad_Juarez
available in latest revision of pytz package (pytz-2022.7.1) So use a similar timezone: America/Boise

opw-3158554

Forward-Port-Of: odoo/enterprise#38881

opw-3289147 Forward-Port-Of: odoo/enterprise#40443

opw-3289147

Forward-Port-Of: odoo/enterprise#40443

Before this commit, the context added to the schedule stat button contained a reference to the active_id value. However, in this case, we actually want the current id of the record that we are looking at, not the id from a previous view. Note that as far as I can tell, almost every use of `active_id` in stat button is wrong. It just usually works because we don't have an active id set, and there is a fallback in the basicmodel to get the current record id instead. However, if a user would ge

Before this commit, the context added to the schedule stat button contained a reference to the active_id value. However, in this case, we actually want the current id of the record that we are looking at, not the id from a previous view.

Note that as far as I can tell, almost every use of `active_id` in stat button is wrong. It just usually works because we don't have an active id set, and there is a fallback in the basicmodel to get the current record id instead.  However, if a user would get to that form view by following some other relations and coming from another form view, then the active_id would not be correct.

Forward-Port-Of: odoo/enterprise#40488

Previously, when a reward was applied on a product, the product was checked against the reward_product_ids field, which is a computed m2m field that contains all the IDS of the products on which this reward is available. In many cases, rewards are available on all products, causing the computation of the m2m to fill it with the ids of all products. This caused performance issues on all DBs with lots of products (~200k) in all flows involving rewards. We can't remove reward_product_ids from th

Previously, when a reward was applied on a product, the product was checked against the reward_product_ids field, which is a computed m2m field that contains all the IDS of the products on which this reward is available. In many cases, rewards are available on all products, causing the computation of the m2m to fill it with the ids of all products. This caused performance issues on all DBs with lots of products (~200k) in all flows involving rewards.

We can't remove reward_product_ids from the data loaded in the frontend in stable because existing JS customisations might crash if they depend on its presence. As such, to keep compatibility with existing databases, an ir.config_parameter has been introduced to opt into the new behaviour. This parameter is set when creating a database so that new databases don't suffer from this performance penalty. For existing databases, the parameter can be set by hand if the old behaviour is not necessary and the performance penalty is an issue in practice, but is unset by default.

When opting into the new behaviour, the reward_product_ids field now always evaluates to an empty recordset, and the desired behaviour should be achieved by evaluating records against the reward_product_domain instead. In the point_of_sale, the products available on rewards are calculated by evaluating each product against the reward when it is loaded. In the loyalty modules, instead of using the in operator on the reward_product_ids field, we instead evaluate the reward product domain against the product, which is much faster. This is always done even when not opting into the new behaviour as the change in implementation cannot be observed outside of timing.

Forward-Port-Of: odoo/enterprise#40455
Forward-Port-Of: odoo/enterprise#40137

Adapts l10n_ec_edi.TaxTotalsComponentForWithhold to the latest changes of its base class account.TaxTotalsComponent - Overridden formatting method renamed to formatData - Formatting method directly called from the super.setup(), therefore super.setup() can't be called anymore, instead rewrote setup() without calling super Forward-Port-Of: odoo/enterprise#40434 Forward-Port-Of: odoo/enterprise#40354

Adapts l10n_ec_edi.TaxTotalsComponentForWithhold to the latest changes of its base class account.TaxTotalsComponent
- Overridden formatting method renamed to formatData
- Formatting method directly called from the super.setup(), therefore super.setup() can't be called anymore, instead rewrote setup() without calling super

Forward-Port-Of: odoo/enterprise#40434
Forward-Port-Of: odoo/enterprise#40354

task-3245969 Forward-Port-Of: odoo/enterprise#38702

task-3245969

Forward-Port-Of: odoo/enterprise#38702

Steps: - Install timesheet and helpdesk app. - Go to timesheet. - Group by ticket field. - Try to add timesheet from grid cell. Issue: - Validation error. Cause: - Cell does not check ticket field on timesheet to add from grid cell. Fix: - Add a method to check on which field user adding timesheet and set that field accordingly, task-3255754 Forward-Port-Of: odoo/enterprise#40417

Steps:
- Install timesheet and helpdesk app.
- Go to timesheet.
- Group by ticket field.
- Try to add timesheet from grid cell.

Issue:
- Validation error.

Cause:
- Cell does not check ticket field on timesheet to add from grid cell.

Fix:
- Add a method to check on which field user adding timesheet and set that field accordingly,

task-3255754

Forward-Port-Of: odoo/enterprise#40417