Saturday, September 5, 2026
19 changes · master
New functionality added to Odoo
This change introduces shared direct debit mandate capabilities that can be reused across payment localizations, reducing duplication and making future regional support easier. It also adds support for Canadian CPA 005 Pre-Authorized Debits, enabling businesses in Canada to collect inbound direct debit payments through Odoo.
Discuss users can now guide AI chat behavior with options such as web search, strict source-based answers, deeper reasoning, and automatic action approval. These controls give teams more flexibility and confidence by making AI responses better match each conversation's needs.
Original PR description
This commit introduces new AI actions in Discuss chats to give users granular control over their AI chat experience. The 3 new actions include: - Web Search: Enables the web search tool (even if not…
This commit introduces new AI actions in Discuss chats to give users granular control over their AI chat experience. The 3 new actions include: - Web Search: Enables the web search tool (even if not in the agent's default skills) and encourages its use. Toggling it off explicitly blocks the agent from searching the web. - Strict to Sources: Restricts the agent's ability to search for answers to exclusively use the provided RAG sources. - Think Longer: Increases the agent's reasoning level/depth. Technical Details: - State Management: The three options are stored as session state attributes, with default values inherited from the agent settings. - Validation: "Web Search" and "Strict to Sources" are mutually exclusive. This rule is enforced and validated on both the frontend and the backend. - API Updates: Compressed the session settings into a single `ai_session_config` dictionary for the `generate_response` API. - Synchronization: State changes from the backend to the frontend are communicated via the mail store. Frontend to backend communication is passed through the `generate_response` payload. - Tests: Adapted existing tests and added new test cases to cover the new configurations and the mutual exclusivity validation. task-6310817
Enhancements to existing features
This update makes mobile form fields easier to scan by simplifying field styling and making required fields stand out through their labels. Phone actions such as calling, SMS, and WhatsApp are now visible as direct icon buttons instead of being hidden in a menu, reducing taps for users on smaller screens.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes the Luxembourg Balance Sheet so two investment-related accounts are reported in the correct categories. It helps companies produce more accurate statutory financial reports and avoids swapped values in the generated XML filing.
Original PR description
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch…
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch to the `LU Company`. - Navigate to Accounting > Accounting > Journal Entries and create and post two journal entries: - One with account `502000 Own shares or own corporate units`. - Another with account `503000 Shares in undertakings with which...`. - Navigate to Reporting > Balance Sheet and check the `III. Investments` section. **Observation:** - `502000 (Own shares...)` is wrongly added under `3. Other investments`. - `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`. In the generated XML report: - `502000 (Own shares...)` balance is added inside `<NumericField id="195">`. - `503000 (Shares in undertakings...)` balance is added inside `<NumericField id="209">`. **Expected behavior:** According to the Luxembourg documentation mapping tables [1], - Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`. - Account `503000 (Shares in undertakings...)` should be mapped to `<NumericField id="195">`. **Root Cause:** At [2], the `account_codes_formula` values are incorrectly assigned: account code `503` is mapped under `2. Own shares`, while account code `502` is mapped under `3. Other investments`. This reverses the expected mapping of the two accounts in the Balance Sheet report. [1]: https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables [2]: https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348 opw-6275340 Forward-Port-Of: odoo/enterprise#130603 Forward-Port-Of: odoo/enterprise#128386
Code cleanup and technical improvements
Partner identification types have been moved into the main accounting partner identifiers framework, reducing duplicated country-specific handling. This simplifies maintenance and helps keep identification data more consistent across Latin American localizations.
Original PR description
The Dominican Republic localization now uses the updated partner identification approach while keeping existing validation rules intact. Business identifiers are stored more consistently: RNC remains on the VAT field, while Cedula is handled as an additional identifier, improving data reliability for local compliance.
Original PR description
Purpose: Adapt the current latam partner identification type to follow the additional identifiers approach introduced in PR: https://github.com/odoo/odoo/pull/259051. The validation logic involving identification types are preserved after the re-implementation. RNC now lives in the VAT and Cedula is an additional identifier. task-6129832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Dominican Republic electronic invoicing now uses the updated partner identification approach while keeping existing validation rules intact. Business tax IDs (RNC) are handled through VAT, and personal IDs (Cedula) are managed as additional identifiers, improving consistency with the broader Odoo platform.
Original PR description
Purpose: Adapt the current latam partner identification type to follow the additional identifiers approach introduced in PR: https://github.com/odoo/odoo/pull/259051. The validation logic involving identification types are preserved after the re-implementation. RNC now lives in the VAT and Cedula is an additional identifier. task-6129832
The mail composer now better supports grouped actions in the add-action menu and chatter composer, so users see more complete and consistently ordered options. It also allows richer inline content and more flexible menu-closing behavior, improving usability for future composer actions.
Original PR description
Extend composer actions to support grouped actions, optional inline OWL components, and configurable action-list closing behavior. Grouped composer actions were previously not supported, causing actions with a `sequenceGroup` to be omitted from the "+" button. This commit adds support for grouped actions in both the "+" button and the chatter composer, ordered according to their `sequenceGroup`. Actions can also render an optional OWL component at the end of their content, aligned to the right, and `closingMode` controls whether the action list closes after an action is selected. Implementation notes: * Added `extraContentComponent` and `extraContentComponentProps`. * Added grouped action support to the "+" button and chatter composer. * Added `closingModeAsDropdown` to control action-list closing behavior. Co-authored-by: Alexandre Kühn <aku@odoo.com> task-6310817
This update aligns invoicing and payment tools with a new standalone direct debit mandate foundation. It also makes Canadian direct debit support easier to discover in settings and improves demo data for faster testing.
Original PR description
On Enterprise side, we extracted base direct debit mandate models, wizards, reports, and views from SEPA direct debit into a standalone module. This commits reflects this change on Community. task-6269131
The website forum sitemap now uses much less memory by avoiding unnecessary loading of large forum post content. This reduces the risk of sitemap failures on high-volume sites and helps search engines access the site map more reliably.
Original PR description
On odoo.com, /sitemap.xml fails dozens of times a day with a 500 `MemoryError` before finally succeeding and being cached. The primary cause is the loading of all forum posts. With this commit, we…
On odoo.com, /sitemap.xml fails dozens of times a day with a 500 `MemoryError` before finally succeeding and being cached. The primary cause is the loading of all forum posts. With this commit, we avoid fetching all fields and specifically the `content` field which is html which can contain embeded images in base64. | | Peak memory | |--------|--------| | Before | 1.7GB | | After | 610MB | ### Before <img width="2505" height="400" alt="sitemap-forum-posts-before" src="https://github.com/user-attachments/assets/0ce3aca9-52ed-46a6-ac9b-245c754a08a7" /> ### After <img width="1864" height="291" alt="image" src="https://github.com/user-attachments/assets/6686b0fc-d0ce-4dc2-b2ff-d34e37695104" /> Another approach could be to load posts in batch and free the memory between each batch. It has been measured and yield very similar results in practice. I chose this approach because it matches the future behavior in version 20.0 (see https://github.com/odoo-dev/odoo/commit/fe186b07475cf15a50558d9bdacd0599c17c39be) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286154
Fixed an issue in Planning where using the default Employees filter in the Gantt view could prevent users from creating or editing multiple planning entries at once. This restores expected bulk scheduling behavior and reduces manual work for planning teams.
Original PR description
## Step to reproduce: - Install Planning - Add "Employees" filter by default to a Gantt ## Result: The multi-create does not work because isManager does not resolve due to the early [return](https://github.com/odoo/enterprise/blob/0bee2f47c7e9d0b9a8d171fccde398a680a73415/planning/static/src/views/planning_gantt/planning_gantt_model.js#L60-L63) task-6535800 Forward-Port-Of: odoo/enterprise#130596 Forward-Port-Of: odoo/enterprise#130369
The SAF-T export now skips journal entries using current asset accounts that were incorrectly included in the report data. This prevents a report generation error for Norwegian companies and helps users produce compliant SAF-T files without manual workarounds.
Original PR description
Currently, an error occurs when generating the SAF-T report for a journal entries with the `asset_current` account type. **Steps to reproduce:** - Install `l10n_no_saft` and `accountant` modules and…
Currently, an error occurs when generating the SAF-T report for a journal entries with the `asset_current` account type. **Steps to reproduce:** - Install `l10n_no_saft` and `accountant` modules and switch to a NO Company. - Go to Contacts and set the ZIP code and state, then add a contact for the NO Company record. - Create a new Journal Entry, click `Add a line`, and set an account of type `Current Assets` (e.g., `1000 Development, acquired`) with the partner set to the NO Company. - Navigate to Reporting > General Ledger. - Click the gear icon and select `SAF-T`. **Error:** `KeyError: 'accounts'` **Root Cause:** At [1], from `19.0`, `asset_current` was mistakenly included in the second-to-last account type condition of the domain. As a result, partners linked to `asset_current` accounts are included in the `customer_vals_list` at [2]. However, `_l10n_no_saft_get_partners_accounts()` at [3] does not retrieve accounts of type `asset_current`. Therefore, when the `if` condition is not satisfied, the `accounts` key is not added to `partner_vals`. Since the partner has already been added to `customer_vals_list` at [2], the SAF-T template at [4] later tries to access `partner_vals['accounts']` when generating the `BalanceAccount` nodes, resulting in the error. **Fix:** This commit prevents the error by removing `asset_current` from the domain, similar to previous versions. [1]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L307-L313 [2]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L356-L362 [3]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/models/account_general_ledger.py#L37-L42 [4]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/data/saft_report.xml#L27-L37 opw-6441743 Forward-Port-Of: odoo/enterprise#127744
This fix prevents an internal OCR-created contact marker from being copied when duplicate contacts are merged. Users can now merge an OCR-created contact into a regular contact with the same name without hitting a validation error.
Original PR description
`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…
`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: `is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/odoo#285150
Merging a contact created through invoice OCR into an existing contact with the same name no longer triggers a validation error. This keeps contact cleanup workflows running smoothly while preserving the OCR-created marker only where it belongs.
Original PR description
`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…
`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/enterprise#129623
The scheduled GST token refresh now correctly handles cases where multiple companies are processed at once. This helps ensure follow-up refreshes are scheduled when any company's token is successfully renewed, reducing the risk of interrupted GST reporting access.
Original PR description
The `_cron_refresh_gst_token` method is called by a cron job. Previously, when scheduling the next cron execution, it checked `self.company_id.l10n_in_gstr_gst_token`. However, since the cron can process multiple companies, relying on `self.company_id` could result in incorrect behavior. In this commit, a flag is introduced to track whether at least one GST token was refreshed successfully. If a token was refreshed, the cron is scheduled to run again after 6 hours. Forward-Port-Of: odoo/enterprise#130317
French electronic invoice exports now assign the correct invoice or credit note type for purchase documents. This prevents vendor bills from being mislabeled as credit notes, reducing the risk of rejection during reporting.
Original PR description
Flow 10 used move.is_inbound() to distinguish invoices from credit notes. While this gives the expected result for sales documents, it reverses the codes for purchase documents. Vendor bills were therefore reported as credit notes and could be rejected for having no preceding invoice reference. Determine the document kind from move_type instead. Regular invoices now use code 380 and credit notes code 381. Self-billed invoices and credit notes use codes 389 and 261 respectively. No Task id Forward-Port-Of: odoo/odoo#286526
GSTR-2B returns now show the correct “Fetch GSTR-2B” action instead of an incorrect “Submit” button once checks are complete. This restores the expected process for retrieving GSTR-2B data and prevents reconciliation from being blocked.
Original PR description
On GSTR-2B returns, do not show the 'Submit' button instead show the 'Fetch GSTR-2B' button once all the checks pass. Clicking it fetches the GSTR-2B data. After the recent tax returns refactor (https://github.com/odoo-dev/enterprise/commit/603443c5a45609145de8be288eadc9e06e63e1f3), GSTR-2B returns wrongly showed a 'Submit' button that is not part of their flow, and there was no longer any way to move the return forward and fetch its GSTR-2B data, blocking the reconciliation. task-6529017 Forward-Port-Of: odoo/enterprise#130075
This fixes the Mexican chart of accounts so accumulated depreciation and amortization accounts are classified correctly. Businesses using Mexican localization will now see asset depreciation calculations produce proper journal entry values instead of zero amounts.
Original PR description
Issue: When creating an asset using an "154.01.01 Vehicles", the depreciation values of the journal entries created are zero Steps to reproduce: 1. Install l10n_mx and enter a Mexican company 2.…
Issue: When creating an asset using an "154.01.01 Vehicles", the depreciation values of the journal entries created are zero Steps to reproduce: 1. Install l10n_mx and enter a Mexican company 2. Create an asset and setting the fixed asset account as 154.01.01 Vehicles 3. Click on "Compute Depreciation" and in the "Depreciation Board" page, all the journal entries created will not have any depreciation values Cause: In the l10n_mx chart of accounts, all accumulated depreciation accounts are set as "expense_depreciation" whereas they should be asset accounts because accumulated depreciation accounts are used to credit asset accounts to decrease asset values. If an account of type "expense_depreciation" is used, then when the depreciation account is credited and the expense account is debited, all financial events will occur within expense accounts, which is why no depreciation values were recorded as the asset balances stay the same. Additionally, the "asset_depreciation_account_id" field on "account.account" has a domain restricting selection to "account_type" of "asset_fixed" or "asset_non_current" Solution: Change the "account_type" of l10n_mx accumulated depreciation accounts from "expense_depreciation" to "asset_fixed" and l10n_mx accumulated amortization accounts from "expense_depreciation" to "asset_non_current" Updrade PR: [odoo/upgrade/pull#10936](https://github.com/odoo/upgrade/pull/10936) opw-6359618 Forward-Port-Of: odoo/odoo#284309 Forward-Port-Of: odoo/odoo#278185
*: ar, br, cl, do, ec, gt, pe, uy Purpose: The goal is to remove l10n_latam_identification_type and centralize it in partner_identifiers in account. task-5013950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update moves partner identification handling for several Latin American localizations into a shared accounting component. It reduces duplicate country-specific logic and helps keep electronic invoicing and statutory reports consistent across Argentina, Brazil, Chile, Dominican Republic, Ecuador, Guatemala, Peru, and Uruguay.
Original PR description
*: ar, br, cl, do, ec, gt, pe, uy Purpose: The goal is to remove l10n_latam_identification_type and centralize it in partner_identifiers in account. task-5013950