Tuesday, March 3, 2026
12 changes · 18.0
New functionality added to Odoo
This update incorporates recent changes to Mexican city listings within the Odoo Enterprise system. This ensures accurate tax reporting compliance for businesses operating in Mexico, aligning with the latest government regulations. The changes were made to reflect the newest cities recognized by the Mexican tax authority.
Original PR description
The Mexican government has recently introduced new cities. This pr adds those cities here as well. task-5883334 Forward-Port-Of: odoo/enterprise#107623
Resolved issues and error corrections
This update fixes a minor issue where the system was incorrectly checking user trust permissions on multiple records instead of a single one. This change ensures data integrity and improves the reliability of account-related processes. The fix was implemented to streamline the system's functionality.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251457
This update corrects a visual glitch where sample data continued to appear after creating new records in certain views (like lists). The fix ensures that sample data is properly disabled when the view is reloaded, providing a cleaner and more accurate user experience. This resolves a previously reported issue impacting the appearance of the control panel.
Original PR description
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed…
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI. Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there. The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode. We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode. task~5980226 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
This update fixes an issue where meeting dates in the CRM were incorrectly displayed as a day after the scheduled meeting, particularly when using different time zones. The fix aligns the displayed date with the user's timezone preference, ensuring accurate meeting scheduling and visibility.
Original PR description
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) -…
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) - Go to the form view of an opportunity - Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity) - In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00) - Go back to the opportunity for view # The problem The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11 # Why The calendar view uses the browser's timezone to manage the dates. The smart button does not. It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly. The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences. opw-5898520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where SMS reminders weren't being sent for calendar events synced with Google or Microsoft. The change ensures that Odoo correctly handles SMS notifications for these synced events, aligning with the intended functionality. This improves the reliability of reminders for users who prefer SMS alerts.
Original PR description
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS…
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS reminder. * Sync the calendar with Google. * Wait for the reminder to trigger. * Observe that no SMS is sent by Odoo. Cause: The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo. Fix: The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master. opw-5172958
This update addresses a potential issue in the transmission of Swiss payroll data. Specifically, a warning is now displayed when the ‘AVS’ (Authorized Value System) is negative, providing clearer guidance for users. This ensures accurate reporting and compliance with Swiss regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update fixes an issue where negative values were appearing in tax reports for carried over tax lines (-81, -82, etc.). The change ensures that the XML generated for tax reports accurately reflects tax calculations, preventing potential reporting errors and improving data accuracy. This resolves a previous bug reported by internal teams.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#108916
This update corrects a display issue where proforma vendor bills were incorrectly shown when accessing or downloading bills through the customer portal. The fix now ensures that proforma bills are only presented for invoices and credit notes, aligning with standard billing practices. This improves the accuracy and clarity of bill information for customers.
Original PR description
When accessing to a bill via the portal, we display a proforma vendor bill, same when we download from the portal, it should not be the case Steps: - Create and confirm a vendor bill - Via the menu action, click on "Share" and copy the link - Open the link -> a proforma vendor bill is displayed - Download the bill -> we get a proforma vendor bill Fix: Allow proforma only for invoices/credit notes opw-5882732 Forward-Port-Of: odoo/odoo#248443
This update resolves a potential data error that could occur when moving folders linked to settings to the trash. The fix prevents a database conflict during the automatic cleanup process, ensuring data integrity and stability. This improves the reliability of the Documents module.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869
A test within the Nilvera e-invoice module failed due to an incorrect invoice data format. This update corrects the test by using the standard sending settings, preventing potential errors and ensuring the invoice generation process works as expected. This ensures the e-invoice functionality remains stable and reliable.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task
This update resolves an issue where the Sendcloud shipping API required product weights to be at least 0.00099. This commit ensures that product weights are now a minimum of 0.001, preventing errors and ensuring accurate shipping calculations through Sendcloud. This improves the reliability of our shipping process.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" />
This update resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for 'early payment discount' (EPD) information, ensuring accurate invoice generation and compliance with accounting standards. This improves the reliability of our invoicing process.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244659