Daily updates from Odoo
Friday, December 19, 2025
17 changes · 19.0
Enhancements to existing features
This update enhances the tracking of errors received from Intervat during tax return processing. Instead of just displaying notifications, error messages are now logged within the tax return chatter, providing better visibility and troubleshooting capabilities. This improves our ability to quickly identify and resolve issues related to Intervat tax returns.
Original PR description
When we receive an error from Intervat, we just display a notification. But it's not optimal to track the errors of a tax return. With this commit, we will also log the error messages in the tax return chatter. task-5425065
Resolved issues and error corrections
This update resolves an issue where document previews were not updating correctly after renaming documents. Previously, the preview displayed the old attachment name even after a successful rename. This change ensures that document previews always reflect the latest, correctly renamed document name, improving data consistency and user experience.
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#101453
Forward-Port-Of: odoo/enterprise#95111This update allows administrators to now modify and permanently save the default size settings for sign item types within Odoo Enterprise. Previously, these sizes were fixed, limiting flexibility. This change ensures sign items can be configured to meet specific requirements without affecting new creations.
Original PR description
The default size of sign item types could not be modified. It can now be updated and stored persistently, without impacting the default size computation for newly created items. task-5420386
This update resolves a bug that occurred when multiple CAF documents were active within a document type, causing errors when opening invoices. The fix ensures the system selects the CAF with the lowest starting number, allowing for proper document sequencing and preventing database errors. This improves invoice processing reliability.
Original PR description
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting…
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number. This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB. Steps to reproduce: - Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5) - Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example). - Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset. In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled. opw-5414350 Forward-Port-Of: odoo/enterprise#102385
This update resolves an error that occurred when generating tax reports for companies not based in Belgium. The fix prevents the system from attempting to parse invalid VAT numbers, which previously caused a technical issue. This ensures accurate tax report generation for all company types.
Original PR description
**Steps to reproduce:** 1. Go to Companies and set a non-BE VAT on the current company, e.g., `US12345678` 2. Go to Accounting → Configuration → Fiscal Positions. 3. Create a new Fiscal Position and set the country to Belgium. 4. Enter a valid Foreign Tax ID, e.g.,` BE0477472701`, and save. 5. Create the taxes. **Issue:** A traceback is raised: `ValueError: invalid literal for int() with base 10: 'US12345678'` **Cause:** This happens because `_be_company_vat_communication` attempts to parse the company's VAT number even when the company does not belong to BE, resulting in invalid VAT formats such as "USxxxxxxx". **Solution:** Return an empty structured communication unless: - the VAT is valid, and - the detected country code is BE, and - the fiscal country is Belgium. This prevents parsing foreign or invalid VATs and avoids the traceback during foreign tax generation. **opw-5368016**
This update resolves an issue where employees acting as their own approvers couldn't modify their overtime requests. The fix adds necessary permissions to access work entries, allowing employees to correctly approve or reject their own time entries.
Original PR description
Employees set as themselves as approvers couldn't modify their attendances due to permission issues with other models. task-5427553
This update fixes a technical issue where payroll CFDIs generated in Mexico were missing crucial relationship information in their XML format. The change ensures that all payroll CFDIs accurately reflect the origin relationships (like substitutions and reimbursements), meeting regulatory requirements and preventing potential errors.
Original PR description
The module already computes and exposes `cfdi_relationado_data` during the CFDI generation process, but the corresponding XML node was never rendered in the CFDI template. As a result, payroll CFDIs with origin relationships (e.g. substitution, related UUIDs, reimbursements) were silently omitting the required `<CfdiRelacionados>` structure. This patch injects the missing XML section into the v4.0 template, iterating over each relation type and UUID, ensuring that the CFDI properly reflects the relationship metadata already computed by the model. Fixes the inconsistency between backend logic and XML output.
A test tour for GS1 barcode scanning was intermittently failing due to a timing issue during data updates. This fix ensures consistent behavior by applying a mutex to the barcode scanning process, preventing data inconsistencies and making the test reliable. The update also includes improvements to the tour trigger and helper methods for greater precision.
Original PR description
Runbot build error: [232683](https://runbot.odoo.com/odoo/runbot.build.error/232683)
This update fixes an issue where users weren't seeing only relevant documents in the systray. The change ensures that activity filters (Late, Today, Future) are correctly applied when navigating from the systray, ensuring users only view documents with pending activities. This improves the user experience and data accuracy.
Original PR description
Clicking on activity counters (Late, Today, Future) in the systray relies on specific "search_default" keys to filter the target model's view. Previously, these specific activity filters were missing from the document search view or had the wrong name, causing the systray to fail to filter the documents correctly when redirected. This resulted in the user seeing all documents instead of only those with the relevant pending activities. Note: the 'My Activities' filter is set to invisible, to align with standard odoo behaviour. Task-5427921
This update fixes an error in the VAT return reporting process for Belgium. Previously, the system incorrectly set a flag to True, even for periods that weren't the end of the year. This change ensures accurate reporting by setting the flag to False for non-end-of-year periods, improving the reliability of VAT calculations.
Original PR description
When the client_nihil field was hidden from the wizard, its computation always set it to True. This was wrong : this field can only be True in the XML when in the last period of the year, so when should_display_client_nihil is True as well. In every other cases, it needs to be False. opw-5184056
This update resolves a problem where WhatsApp templates were incorrectly linked to the default company, preventing users from sending sign requests from other companies. The change filters templates based on user access rights, ensuring the correct templates are available for each company and eliminating access errors.
Original PR description
Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies. This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company. task-5424781
This update fixes an issue where the hours view would overlap with the progress bar display in the Gantt view when work entries were activated in sparse mode. This enhancement ensures a cleaner and more accurate visual representation of work progress, improving usability for users.
Original PR description
When the work entry is activated in sparse mode prevent the hours view from overlapping. task-5410789
This update fixes an issue where the price displayed on Italian POS receipts for multiple product purchases was incorrect. The fix ensures that the unit price, rather than the total line price, is used when generating the receipt, resulting in accurate pricing for Italian customers. This improves the reliability of financial reporting and customer billing.
Original PR description
Currently, when buying multiple quantities of the same product, the unit price value sent to the italian printer is incorrect. Steps to reproduce: ------------------- * Set up italian printer for one shop * Open shop * Add a product to the order with a qty 3 and a price unit of 1 * Pay the order * Print italian receipt > The price total for the 3 product says 9 instead of 3 Why the fix: ------------ When computing the order lines details we were using `total_included` for the unit price which takes into account the quantity. Per definiton, it's not the price for 1 unit. opw-5404877
This update simplifies the handling of errors when using the AI's response generation feature in live chat. Previously, a technical traceback was displayed alongside a friendly AI-generated message. Now, errors are handled more gracefully, providing a better user experience and aiding support teams by removing technical details.
Original PR description
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function…
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms. The problem with this approach is two-fold. Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless. Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out. In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat. task-5177169
This update resolves an issue where field syncs in the Quote calculator spreadsheet would disappear after inserting a new row. The fix ensures that field syncs are correctly maintained when rows are added, preventing data inconsistencies and improving spreadsheet functionality. This ensures accurate data synchronization for sales quotes.
Original PR description
Steps to reproduce: - create a Quote calculator spreadsheet - add a field sync on A1 - autofill it down on a few cells - select row B - right click and "Insert row above" => some field syncs disapeared Forward-Port-Of: odoo/enterprise#101367 Forward-Port-Of: odoo/enterprise#101066
This update resolves an issue where VAT reports for Belgian companies were incorrectly setting the 'Client Nihil' field to 'YES' outside of the year-end. The change reintroduces a checkbox option for this setting, aligning with Belgian regulations regarding when this option is permitted. This ensures accurate VAT reporting and avoids potential compliance issues.
Original PR description
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year…
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf ## Cause: Prior to 18.3, nihil was a checkbox option on export Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date This PR brings back the Client Nihil checkbox in 19.0 But didn't change the default value Causing the issue to still be present https://github.com/odoo/enterprise/pull/99496 ## Steps to reproduce: - Select the Belgian company - Open the Tax Return and select the VAT Return - Click Returns and enter an opening date in January - Click Review for the first available report - Ignore errors and return to previous page - Click on Submit -> Download XML - Before the fix, ClientListingNihil is set to YES ## Potential remaining issue: The legal document specify that it should also be checked in case of "cessation d’activité" So it may be interesting to consider adding the option back opw-5184056 Forward-Port-Of: odoo/enterprise#98982
This update resolves an issue where subfolders within document categories weren't appearing in the search panel when accessed from other applications. Previously, users would see the full folder structure, but the search functionality wouldn't reflect it. This change ensures a consistent and accurate search experience for all document types.
Original PR description
...when coming from another app. Reproduce: 1. Go to a fleet vehicle record and open its 'Documents' stat button. 2. You end up in the Fleet folder, where you see subfolders as kanban cards, but they are not in the search panel. Task-5272030