This update streamlines connections to remote SaaS databases by automatically authenticating users via OAuth SSO. Previously, users created in remote databases weren't automatically authenticated. Now, when a user connects, their identity is securely written to the remote database, enabling seamless and immediate access.

## [IMP] databases: SSO smooth connection and setup

The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.

To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.

Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.

After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.

task-id: 6071808

## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
    - We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time. 
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
    - [x] add it to all server on which the user has access
    - [x] add it to a specific server (may require the db list view on `res.users`
    - [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
    - The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
    - [x] add a config in the settings

Forward-Port-Of: odoo/enterprise#112369

This update introduces a streamlined process for requesting and managing DMFA reports, allowing for corrections and consultations on employee payroll data. The system now automatically detects changes in payslips and triggers a consultation request, ensuring accurate reporting for tax compliance in Belgium. This improves data integrity and simplifies the reporting process.

- Introduce the ability to create a DMFA consultation and modification reports for all employees or a selected subset
- Can be done independently or through a changes detection flow (warning if payslips changes detected -> send a consultation request -> sync data -> send mofication request)
- Add NaturalPersonState model to store the latest changes for an employee coming from changes in payslips or consultations
- Dynamic fetching of the latest DMFA XSD schema validator instead of being store in the codebase
- Dashboard warning in case of payslips changing for a submitted report
- Rename declaration_type to declaration_method for better naming of the new variable defining the different types of declarations
- Sync DMPI files and Consultation files

task-5404502

This update allows businesses to directly generate a BIR 2307 withholding tax certificate for individual vendor bills within Odoo. Previously, these certificates required manual creation. Additionally, the update reduces the number of blank rows in the 2307 report, ensuring the certificate fits on a single page for easier processing.

Add the ability to issue a BIR 2306/2307 withholding tax certificate for a single confirmed vendor bill directly from the bill.

task-6219272

This update introduces the ability to track and manage employee mobility budget expenses directly within Odoo. It adds new features to record and categorize these expenses, providing better visibility into employee travel costs and supporting compliance. This enhancement improves financial reporting and simplifies expense management for HR teams.

task-6034871

This update enhances the accuracy of Belgian payroll tax calculations by providing more flexible options for tax withholding and ensuring calculations are based on the correct withholding tax amount, not the taxable salary. It also adds new features like a total tax target option and clarifies calculation methods for users, improving overall payroll management.

The percentage option was previously computed on the taxable salary instead
of the withholding tax amount. Also, a total guaranteed tax ceiling option
and a net salary safety cap were missing.

 - Change % option calculation to scale against withholding taxes (PP).

 - Rename '€/month' option to '€ extra/month'.

 - Add '€ in total /month' option to pay a target total tax amount.

 - Add descriptive help messages to clarify calculation methods for users.

 - Cap the deduction automatically to never exceed available taxable salary.

Task-ID: 6326856

This pull request includes several improvements to the planning module's field service functionality, focusing on better organization, user experience, and feature control. Key changes include reordering slot states for improved visual clarity, streamlining field service settings, and enhancing the 'My Planning' menu for internal users.

This update simplifies the payroll offboarding process by hiding irrelevant fees and preventing duplicate payslip generation. The system now intelligently handles holiday attest requests, avoiding errors caused by recent hires and ensuring a smoother workflow for HR staff.

First, the "Termination Fees" generation button is now hidden if the employee fully works their notice period. Since these fees are not legally applicable in this scenario, hiding the button removes visual clutter and prevents HR officers from generating invalid payslips by mistake. Action names have also been refined to provide clearer terminology.

Secondly, the generation logic for both termination fees and holiday attests has been updated to be idempotent. Previously, clicking the buttons multiple times would spam the system with duplicate draft payslips. The logic now intercepts the creation process: if a non-cancelled payslip already exists for the target structure and period, the system acts as a smart redirect and simply reopens the existing record(s).

Finally, the system now validates the employee's first contract date before attempting to generate an N-1 holiday attest. If the employee was hired in the current year (Year N), the N-1 attest generation is entirely skipped, preventing the creation of empty, nonsensical documents that would otherwise require manual deletion.

task-6296066

This update enhances the initial setup of the Point of Sale (POS) system by incorporating configuration and session IDs. These IDs allow the system to correctly identify and operate within specific store environments, improving accuracy and functionality. This change primarily impacts the enterprise and IoT POS modules.

*: l10n_it_pos

In this commit:

-  Add `pos_config_id` and `pos_session_id` to the global `odoo` variables initialized in `setupPosPrepDisplayEnv`.
- Use `self_ordering_mode` from the global `odoo` variables to determine whether the config is a kiosk configuration.

Task-6190644

This update enhances data security by preventing sensitive payroll information (like wages and costs) from being visible to unauthorized users. A recent change in how tracking messages are generated made previous security controls ineffective. This fix ensures only payroll team members can access these critical details.

When a new version is created from the salary configurator, a tracking message summarizing field changes is posted on the employee chatter. This message may contain sensitive payroll information such as wage and yearly cost, which should not be visible to users outside the payroll group.

Previously, all tracking messages on hr.employee were visible to any user with access to the employee record. After the mail tracking refactor introduced in task (3645865) (https://www.odoo.com/odoo/project/1251/tasks/3645865), tracking values are now rendered directly into the message body, making the old field-level filtering mechanism no longer applicable.

To restore payroll visibility restrictions:
* Tracking values linked to payroll-restricted fields are separated from regular tracking values during `_track_log`.
* Payroll-sensitive tracking values are posted in a dedicated tracking message using the subtype `mt_hr_payroll_sensitive`.
* Regular tracking values continue to use the standard tracking flow and remain visible to all users with access to the employee chatter.
* Employee chatter message fetching is overridden to hide payroll-sensitive messages from users outside `group_hr_payroll_user`. A test was also added to ensure payroll-sensitive tracking messages remain hidden from non-payroll users.
Task: 4985543

This update ensures that internal users can always see tickets they've been assigned to within the customer portal, regardless of their company access. Previously, this wasn't possible, creating a gap in internal support workflows. This change improves internal team efficiency and visibility.

Show the internal ticket user if assigned to a ticket as a customer, even if no access to the company this ticket belongs to.

Adjust the domain of filtering tickets to show the assigned ticket to him in the portal.

Task-4049642

This update resolves an issue where duplicate preparation cards or tickets were sometimes generated when using the UrbanPiper POS integration. A recent code change introduced redundant order creation processes. The fix reuses the existing, reliable flow that checks if the order has been sent to the kitchen, preventing duplicates and ensuring accurate ticket generation.

Steps to reproduce:
=
* Create a POS configuration with UrbanPiper enabled.
* Open a POS session.
* Place and accept an UrbanPiper quick order.

Issue:
=
* In some cases, two preparation cards or preparation tickets are generated for the same order.

Reason:
=
* A recent refactor of the preparation order/preparation order line flow introduced multiple code paths that could trigger preparation order creation for the same order.

Fix:
=
* Reused the existing preparation order creation flow that already checks whether the order has been sent to the kitchen/preparation display.
* This prevents duplicate preparation order creation and avoids generating multiple preparation cards/tickets for the same order.

task-6273306

This update fixes a bug in the Preparation Time report for Point of Sale, ensuring that preparation durations are displayed correctly based on the user's current timezone. Previously, the report always used the timezone of the system administrator, leading to inaccurate data. This change improves reporting accuracy and provides users with reliable preparation time insights.

In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot / superuser), not the timezone of the user viewing the report. Changing the user, company, or browser timezone had no effect on the graph until the module was upgraded again.

Steps to reproduce:
-------------------
* Configure a Preparation Display and create POS orders with measured preparation times.
* Open Point of Sale → Reporting → Preparation Time.
* Note the hour bucket used for the orders.
* Change your user timezone in Preferences and reload the report.

> Observation:
The hour buckets stay the same. Before the fix, they only changed after upgrading `pos_enterprise`, because the timezone was embedded in the SQL view created during `init()` as superuser.

Why the fix:
------------
Replace the static PostgreSQL view with a dynamic `_table_query` so `order_hour` is computed with the current user's timezone on each report read. `init()` now only drops the legacy view instead of recreating it with a frozen timezone.

opw-6220248

Forward-Port-Of: odoo/enterprise#118365

This update fixes a confusing issue in the budget report where budget lines were labeled with repetitive names. The change now includes related analytic accounts in the display name, making budget lines much easier to distinguish and understand. This improves report readability and data analysis.

Budget report grouping by budget line displayed the budget name for
every line, which made different lines indistinguishable and produced
labels like "Budget 2026 x", "Budget 2026 x (2)", etc.

Compute a more specific display name for budget lines by appending the
analytic accounts concerned by the line to the budget name. Also expose
Budget Line as a first-class group-by in the Budget Report search view
and apply it by default when opening the report.

task-6293065

Forward-Port-Of: odoo/enterprise#121204

This update automatically updates the map routes when a user changes their location. Previously, users had to manually refresh the map to see the correct routes. This improvement ensures a smoother and more accurate user experience when navigating maps within the Odoo Enterprise application.

In this commit, we ensure that the map is updated with the newly computed routes if the user position changes. Prior to this commit, the user had to manually trigger an update to correctly view the updated routes.

Forward-Port-Of: odoo/enterprise#120966

This update resolves an issue where appointment filters were incorrectly persisting across different views (Kanban to Gantt). Now, filters are automatically cleared when switching views, ensuring accurate appointment display and preventing bookings from being hidden. This improves the user experience for managing appointments.

In this commit:
- When switching from Kanban to Gantt view, the POS-specific filters `date_filter` and `hour_filter` (added by `PosAppointmentSearchFilter`) were persisting on the shared SearchModel, incorrectly hiding bookings.
- Now these filters are removed when activating the Gantt view.
- Clear these filters when changing views and add a tour test to cover the
Kanban → Gantt navigation flow. Also extract common appointment view tour
helpers for reuse.

Task:6276594

Forward-Port-Of: odoo/enterprise#120368

This update resolves an issue where tours were behaving unpredictably. The team refined the triggers used in the tours to ensure they consistently activate when intended, leading to a smoother and more reliable user experience. This change focuses on internal improvements to the Odoo Enterprise application.

Fix undeterministic tours by making some triggers more precise in a few steps.

This update fixes a reporting issue where tax tags weren't correctly applied to invoices using group taxes. The change ensures that all child tax tags associated with a parent tax are included in generic reports, accurately reflecting tax calculations for Philippine businesses. This improves the reliability of financial reporting.

When using group taxes, the base invoice lines only store the parent tax in the `account_move_line_account_tax_rel` table. Because of this, if a child tax within the group contains a specific tax report tag (e.g., tag 33A on the SC/PWD exempt component introduced in the base localization), the generic report query would previously fail to pick up those base lines.

This commit updates the SQL join conditions in `l10n_ph_generic_report.py` to also match `account_tax.id` against the child taxes of the linked parent tax using the `account_tax_filiation_rel` table. This ensures that base lines are correctly reported under the tags of their respective child taxes.

Task-6032306

See: odoo/odoo#270764

This update fixes an issue where scanning an unknown barcode in the Point of Sale (POS) system didn't automatically open the product creation form. The fix removes a redundant check for API keys, ensuring the form opens correctly regardless of whether a barcode lookup key is configured. Users can now consistently create products by scanning barcodes.

When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.

Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.

opw-6295221

Forward-Port-Of: odoo/enterprise#120256

This update streamlines the automatic onboarding tours within several Odoo modules (Helpdesk, Planning, Sale, Web Studio, and Knowledge) by removing unnecessary formatting wrappers. This fix resolves validation errors and ensures a smoother, more reliable onboarding experience for new users. The change also adds specific validation rules for onboarding tours.

…ntent

This update fixes an issue where report titles within Odoo Knowledge embeds were not consistently translated. The solution involves retrieving the report's name directly, streamlining the process and eliminating a previous fallback mechanism. This ensures accurate and localized report titles are displayed in Knowledge.

Problem:
The title of the report is not translated properly in embeds in Knowledge. Considering how `data-embedded-props` are fed, I don't think we can directly feed the translated value that easily ?

Possible solution: we have the report_id in options, we can just read the name ?

Pro: we wouldn't even need to provide the report name in the first place (so that fallback thing is most likely useless).
Cons: There's a bit of back-and-forth with the additional read.

Should most likely be fixed in 19.0+ and not in master if we want to fix it.

task-none (follow-up of discussion in https://github.com/odoo/enterprise/pull/120077#discussion_r3389814591)

This update removes an outdated coding technique, `useLayoutEffect`, from the Web Studio module. This change is part of a larger effort to modernize the system and prepare for the upcoming OWL3 migration, ensuring a smoother and more efficient user experience.

Remove useLayoutEffect usage in web_studio utils.js as part of OWL3 migration.

This update removes a specific code snippet (useLayoutEffect) from the POS platform. This change was made to simplify testing and prepare for a future update using a more efficient API. The removal is expected to improve the overall performance and stability of the POS system.

Commented out useLayoutEffect calls to test coverage before replacement with OWL3 API.

This update removes a temporary code change in the Knowledge module's chatter integration. This was a preparatory step for a future update using the standard OWL3 API, streamlining the module's functionality. The removal has no impact on the core Knowledge features.

Remove useLayoutEffect from chatter_patch.js in knowledge module. This is a throwaway commit that will be replaced with the OWL3 native API implementation.

This update simplifies the Frontdesk module by removing the 'cancel' visitor state, which was no longer used. This streamlines the visitor tracking process and reduces unnecessary complexity within the system. This change improves the overall user experience and maintenance of the Frontdesk feature.

This commit removes the cancel state from the frontdesk visitor states, as it is no longer relevant.

Task-6312796

This update removes the useLayoutEffect function from several Odoo modules to facilitate testing and ensure compatibility with the upcoming OWL3 replacement. This change is part of a controlled experiment to improve test coverage and prepare for a key system upgrade. It's a technical refactoring focused on testing.

Commenting out useLayoutEffect to check test coverage before applying OWL3 replacement.

This update removes an outdated technique used in the documents viewer to improve its performance and stability. The change is part of a larger effort to migrate to the OWL3 system, ensuring a smoother user experience for viewing documents. It addresses a technical issue related to document rendering.

Remove useLayoutEffect usage in documents_file_viewer.js as part of OWL3 migration. Effect bodies are commented out to detect test failures before applying the proper OWL3 replacement.

This update replaces an outdated technique with a modern one, ensuring the knowledge chat feature continues to function reliably. The change addresses a deprecation issue within Odoo's OWL3 framework, streamlining the code and maintaining core functionality without requiring additional configuration.

Replaced `useLayoutEffect` with `useEffect` (from `@odoo/owl`) because `useLayoutEffect` is deprecated in OWL3.

`useEffect` in OWL3 has no dependency array — it auto-subscribes to any reactive values accessed inside the callback. The effect reads `this.props.threadId` and `this.state.thread` access-right fields directly, so OWL3 tracks those dependencies automatically. This restores the original logic: detecting thread changes, resolving the `chatterThreadReady` promise, and updating toolbar visibility without requiring an explicit dep list.

The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_file_as_attachment_from_knowledge
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_file_as_message_attachment_from_knowledge
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_template_as_message_from_knowledge
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596754/build/114855772

This update removes a potentially performance-impacting technique (useLayoutEffect) from the VoIP search bar. This change improves the stability and responsiveness of the search functionality, aligning with our ongoing efforts to optimize Odoo's performance. The change also prepares for the integration of the OWL3 API.

Commented out useLayoutEffect usage to identify test coverage before applying OWL3 replacement.