Daily updates from Odoo
Wednesday, April 29, 2026
18 changes · 18.0
Resolved issues and error corrections
This update resolves a bug preventing website appointment syncs from appearing in Outlook calendars. Previously, a timing issue with the synchronization cron prevented events created through website appointments from being properly synced. The change ensures all calendar events, including those from website appointments, are consistently synchronized with Outlook.
Original PR description
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of…
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app). To reproduce, Default "Outlook: synchronization" is ran every 12 hours. 1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00 2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar. opw-5212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that signatures are only applied to the original sales order document generated by the signature process, not to subsequent PDF copies. Previously, signatures were duplicated on all generated PDFs, leading to inconsistencies. This change streamlines the process and maintains accurate signature records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate menu to create a certificate before setting it in the main accounting configuration. Now, users can directly create and edit digipoort certificates within the existing settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566
This update corrects a situation where invoices rejected by the tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears this 'sent' flag when an invoice is rejected, allowing invoices to be re-submitted after the issue is resolved. This improves the invoicing process and reduces manual intervention.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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 corrects a technical issue that could cause problems with voice message tests in Odoo. Specifically, the system was prematurely resolving promises related to voice playback, leading to potential errors. This fix ensures that the voice player is fully drawn before promises are resolved, improving test reliability and stability.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783 Forward-Port-Of: odoo/odoo#261795
This update fixes an issue where Sale Order Line descriptions were incorrectly displaying vendor-specific information instead of the standard product name. The change ensures the correct product name is used in the description, regardless of whether the customer and vendor are the same. This improves data accuracy and consistency in sales orders.
Original PR description
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create…
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create a Sale Order using this same vendor as the Customer. 4. Add the product to the Sale Order Line (SOL). Reference [video](https://drive.google.com/file/d/1wqsOoE00kOowm9puGXgDTGdV9Xkkwton/view?usp=sharing) Observation and issue: ------------------------ 1. Before clicking outside the SOL, the description remains unfilled despite the availability of a vendor product name and code. 2. Upon clicking outside the SOL, the description displays only the vendor product name and code incorrectly overriding the standard product name. Cause: --------- * The SOL description([_compute_name](https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/sale/models/sale_order_line.py#L406)) depends on product's `display_name`, but missing dependencies prevent `_compute_display_name` from being triggered before saving. For reference, POL description: https://github.com/odoo/odoo/blob/a877beaeeb45a2ca3d68bf423f9948f58f6c64aa/addons/purchase/models/purchase_order_line.py#L369-L370 * When the customer and vendor are the same, the `display_name` is computed using vendor context (`partner_id`), causing vendor-specific values to override the product name. https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/product/models/product_product.py#L538-L548 Solution: ----------- * Add the required dependencies to ensure the SOL description is computed correctly . * Skip vendor-based naming when the seller and customer are the same, and fallback to the default product name. opw-5262670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where expense or profit entries were incorrectly appearing in both the current and previous year's Profit & Loss statements. The underlying calculation was flawed, leading to inaccurate reporting. This ensures balance sheet reports accurately reflect financial data.
Original PR description
When generating an expense or profit entry for the current year and then opening the balance sheet for that same year, the entry appears in both the current year’s P&L and the previous years’ P&L. This happens because the previous years’ balance includes all entries and then subtracts the current year, but the subtraction was applied incorrectly (it was effectively doing the inverse). opw-6020381
This update resolves an issue where unit prices were not being rounded correctly when generating PEPPOL invoices. This fix ensures accurate pricing calculations for international trade transactions, improving data integrity and compliance with PEPPOL standards. The change reverts a previous commit that introduced this rounding problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870
A test within the MRP module was failing due to a dependency on a module only available in the Enterprise version of Odoo. This update removes the problematic dependency, ensuring the test now runs successfully across both Community and Enterprise environments. This resolves a consistent test failure and improves overall test coverage.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L494 runbot-242612
This update resolves an issue in the LDAP authentication testing process where the test left behind data in the database. By switching to a simpler `HttpCase` test setup, the problem is fixed and paves the way for adding another test to address a related bug. This ensures the stability and reliability of our LDAP integration.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#261743
This update resolves a critical issue where the Libro Diario report crashed on large databases due to excessive memory usage. The fix implements a more efficient, 'lazy-loading' architecture to handle large datasets, ensuring the report remains accessible and reliable. This change also ensures compliance with accounting regulations.
Original PR description
Loading the Libro Diario (Daily Journal Report) on production databases with large volumes of accounting data causes the Odoo server to crash with a MemoryError, killing the worker process and making…
Loading the Libro Diario (Daily Journal Report) on production databases
with large volumes of accounting data causes the Odoo server to crash
with a MemoryError, killing the worker process and making the report
completely inaccessible.
#### Root Cause
The report used a flat, single-tier architecture that loaded all matching `account.move.line` records at once.
Profiling revealed that `_dynamic_lines_generator` attempted to materialize the entire result set into memory via `dictfetchall()` without LIMIT or OFFSET.
Additionally, an `INNER JOIN` on `res_partner` excluded transactions lacking a partner, rendering the report legally non-compliant.
#### Fix
Implemented a two-tier lazy-loading architecture following the General Ledger pattern:
* **Tier 1 (`_dynamic_lines_generator`):** Groups entries by date using SQL `GROUP BY`. Returns summary lines per calendar day (max 31 lines for `this_month`).
* **Tier 2 (`_report_expand_unfoldable_line_libro_diario_day`):** Loads specific `account.move.line` records only when a day is expanded (`load_more_limit = 80`).
* Additional Changes:
- Changed `default_opening_date_filter` from `this_year` to `this_month`.
- Enabled `filter_unfold_all` and `load_more_limit` in XML.
- Switched to `LEFT JOIN res_partner` to include all economic transactions.
- Overrode `_get_domain` to remove the mandatory `partner_id` constraint.
The new architecture remains fully compliant with Articles 125-128 of Regulatory Compliance (Decreto 2649/1993).
opw-6023518This update fixes a bug where users without the necessary permissions were encountering errors when trying to access their profile information. The team added a field to the user data structure to allow access to country codes, resolving the permission issue and ensuring all users can view their profile details.
Original PR description
Issue: - When a user without access rights tries to view their profile, a permission error is raised. - Issue PR: https://github.com/odoo/odoo/pull/254162 Fix: - Added `employee_country_code` to SELF_READABLE_FIELDS in `res.users`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255260
This update resolves an issue where price rounding errors in Peppol were causing incorrect CUFE generation. The change ensures that all currency amounts are truncated to two decimal places, aligning with DIAN documentation requirements. This improves the accuracy of financial reports for Colombian businesses using Odoo.
Original PR description
**PROBLEM** PR https://github.com/odoo/odoo/pull/255358 fixed price rounding issues in Peppol. This could lead to LineExtensionAmount having more than 2 decimal places, which messed up the CUFE generation. This PR ensures we truncate to 2 decimal places as told in the DIAN documentation. opw-6169870
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies the necessary adjustments to the untaxed amount, aligning with how tax calculations are handled. This ensures accurate financial reporting related to UBL imports.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Odoo's website redirects were failing due to an unreliable method of determining URL canonicalization. The change replaces a problematic setting with a standard Werkzeug feature, ensuring consistent and accurate redirects across different server configurations. This improves website stability and reduces potential 404 errors.
Original PR description
Description of the issue/feature this PR addresses: The _is_canonical_url() method currently relies on `REQUEST_URI` being present in the WSGI environment to determine whether a request URL is canonical. However, `REQUEST_URI` is not part of the WSGI specification and is not consistently populated by Werkzeug (used by Odoo's default HTTP server) or reverse proxies like Traefik. As a result, this method fails in some setups, leading to incorrect redirects or 404s for otherwise valid URLs. Desired behavior after PR is merged: This patch replaces the reliance on `REQUEST_URI` with `request.httprequest.full_path`, which is a reliable, Werkzeug-generated representation of the full request path. This makes Odoo more compatible with WSGI-compliant servers and modern deployment environments. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Backend' button in Point of Sale was causing a session to be deleted twice, leading to potential data inconsistencies. The fix ensures the session deletion method checks if the session has already been removed, improving stability and data integrity. This addresses a technical bug impacting session management.
Original PR description
Before this commit, when clicking on the "Backend" button of a session in "Opening Control" state, the delete_opening_control_session method was called twice, while the first call already deleted the session. The problem was that the method is overridden in the pos_urban_piper module, and it did not check if the session was already deleted. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that occurred when users clicked the 'Backend' button within a specific session state. The issue stemmed from a double deletion of the session, which has now been prevented by a code adjustment. This ensures a smoother and more reliable user experience.
Original PR description
Before this commit, when clicking on the "Backend" button of a session in "Opening Control" state, the delete_opening_control_session method was called twice, while the first call already deleted the session. The problem was that the method is overridden in the pos_urban_piper module, and it did not check if the session was already deleted. opw-6114420
This update resolves a bug in the Mod347 BOE export for Spain, specifically related to cash payments. Previously, invoices under €3,005.06 would incorrectly include a Spanish company in the export report. This change ensures accurate reporting by removing unnecessary partners from the export based on the intended logic.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114331 Forward-Port-Of: odoo/enterprise#110947