Daily updates from Odoo
Monday, March 16, 2026
8 changes · 19.0
New functionality added to Odoo
This update introduces a new module, 'obox,' to connect and manage devices similar to the Odoo FDM for Belgium. The initial step allows users to register an Obox device, capturing its IP address and available services within the Odoo system.
Original PR description
The Obox (same platform as the Odoo FDM for Belgium) will allow interfacing with hardware devices, and is intended to replace the functionality of the IoT box. This commit only adds the ability to pair an Obox to the database, and see its IP and available services.
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It adapts existing DIAN EDI functionality to generate invoices directly from the POS store, eliminating the need to manage invoices in the Accounting App. This improves efficiency and compliance with Colombian regulations.
Original PR description
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App.…
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store. This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation. Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents). task-4038651 Forward-Port-Of: odoo/enterprise#78742
Resolved issues and error corrections
This update fixes a performance issue with the budget report, ensuring it runs efficiently when the account_budget_purchase module is installed. Previously, a change bypassed a key optimization, leading to slow report generation times. The fix restores the original performance improvement.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127
This update fixes an issue where timesheet descriptions were being duplicated when updating values in the grid view. The fix ensures that new timesheet lines created from updated values retain the original description, maintaining accurate reporting and data consistency. This improves the usability of the timesheet feature.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes these rental amounts, ensuring more accurate reporting and compliance with local tax regulations. This improves the reliability of payroll data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919
This update resolves an issue where custom snippets created in the website builder wouldn't display their dynamic content in the preview. The fix ensures that dynamic content is correctly reflected when a custom snippet is saved and previewed, addressing a visual discrepancy impacting user experience. This was caused by a change in the website builder's architecture.
Original PR description
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are…
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet. This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview. Steps to reproduce: - Open website builder - Add a dynamic snippet (for example "Events") - Save the snippet as a custom snippet - Click on "Custom" snippet category - Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5427353 Forward-Port-Of: odoo/enterprise#108912
This update resolves an issue where text fields in Odoo Sign PDFs were incorrectly displayed as checkmarks. The fix ensures that text field values are accurately rendered, preventing misinterpretation of standard text fields as checkboxes during the PDF flattening process. This improves the accuracy and reliability of digital signatures.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260
This update resolves issues with physical card processing in the UK, specifically around missing ETA information and incorrect currency handling. It also adds comprehensive testing for physical cards and improves logging for easier debugging, ensuring smoother expense reporting.