Daily updates from Odoo
Wednesday, March 25, 2026
16 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where fields weren't being created correctly within Odoo. The fix ensures that fields are properly populated during the creation process, improving data accuracy and reliability. This primarily impacts HR and reporting modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
This update resolves an issue where the AEAT tax report file was being rejected due to an incorrect date format. The fix ensures the file includes a default date ('00000000') when the procuration date is not specified, aligning with AEAT's requirements and allowing successful file uploads.
Original PR description
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting >…
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting > Tax Report. - From the smart button, select `Report: Tax Report (Mod 390) (ES)` and choose the year as `This Financial Year`. - Download the `BOE` file using the dropdown and fill the wizard fields (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345). - Upload the generated .txt file to the AEAT portal. (AEAT credentials are required) **Observation:** AEAT rejects the file with: `Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'` **Root cause:** At [1], when `judicial_person_procuration_date` is `false`, an empty string is written to the BOE file, resulting in blank spaces in the exported file. This does not comply with AEAT’s required numeric format and causes the file to be rejected. **Fix:** This commit ensures the file contains '00000000' when `judicial_person_procuration_date` is false, complying with AEAT numeric format requirements. [1]: https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696 opw-5995290 Forward-Port-Of: odoo/enterprise#109652
This update resolves an issue where users couldn't add reactions to messages within the Discuss module, specifically when using the mail_group model. The fix ensures that the 'add reaction' button isn't displayed for message types that don't properly support reactions, improving the overall stability and usability of the Discuss feature.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050 Forward-Port-Of: odoo/enterprise#111673 Forward-Port-Of: odoo/enterprise#111271
This update ensures that all contract sign-off and validation steps are completed before the applicant's process ends. This prevents inconsistencies in the system's state and improves the reliability of our HR processes. It’s a small fix to enhance data accuracy and process repeatability.
Original PR description
This commit adds final steps after the applicant contract being signed to let the actual sign & validate fully finish before ending the tour to avoid unconsistent state and be more reproducible. runbot-241162
This update resolves an issue in Odoo's Web Studio where field visibility settings (based on user groups) were not consistently applied. Previously, toggling the 'Show invisible Elements' checkbox didn't always retain the intended hidden state. This fix ensures that fields remain invisible when a user lacks the necessary access permissions, improving the consistency and usability of the Web Studio interface.
Original PR description
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the "Show invisible Elements" checkbox - Click on the same field => The field is marked as invisible - Add an invisible condition => The invisible condition is lost (but still applied on the view) Cause of the issue ================== In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups). The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled. But this causes the actual value of the invisible attribute to be lost. Note that this also applies to the column_invisible attribute. Solution ======== If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute. We then use that value in the editor, when present. opw-6026971 Forward-Port-Of: odoo/enterprise#111751 Forward-Port-Of: odoo/enterprise#111299
This update corrects an issue preventing Romanian SAFT reports from passing validation. The team restored a key data element and used the correct, sanitized bank account number, ensuring compliance with Romanian tax regulations. This resolves a technical problem impacting report accuracy and usability.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, without this node, the SAFT is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277 Forward-Port-Of: odoo/enterprise#111664
A recent update caused Studio Approval Rules to be unexpectedly deleted from the database during updates. This fix prevents the ORM from removing these rules, ensuring they remain active. The issue was triggered during an upgrade from 18.0 to 19.0 and is now resolved.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update fixes an issue where project budget totals were incorrectly summing expense and revenue amounts. The fix ensures that expenses and revenue budgets are calculated and displayed accurately within the project dashboard, providing a more precise view of project financial status. This improves reporting accuracy and helps users manage project budgets effectively.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. Now, all times are correctly formatted for each user, improving the overall user experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update corrects a legal issue where certain invoice PDFs generated by the l10n_gt_edi module were missing required tax complements. The fix ensures that all invoices for document types FCAM, FCAP, and FESP now include these complements in the PDF format, complying with legal requirements. This prevents potential compliance problems.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update prevents data merge operations from silently failing due to timeouts. Instead, a warning notification is displayed, suggesting users reduce the number of records merged and reloading the model upon successful completion. This enhances the reliability and user experience of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update corrects an issue where ISO20022 files generated for Swiss companies were being incorrectly formatted, leading to bank rejections. The fix ensures the correct 'PAIN 09' version is used, resolving compatibility problems and allowing successful file transmission to banks. This upgrade dynamically updates existing databases to maintain compliance.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle offline scenarios, preventing tracebacks and ensuring smoother operation for users with intermittent internet connections. This improves the reliability of the Italian POS system.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update resolves an issue where only administrators could delete work entry types within the payroll module. Now, users with SUPERUSER permissions can delete these types, streamlining payroll configuration and reducing reliance on technical support. This change improves operational efficiency for HR and payroll teams.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update resolves a problem where translations were not appearing correctly in the Chilean E-Invoicing module, specifically on Ubuntu Jammy and Debian Bookworm operating systems. The change converts a complex list comprehension to a standard for loop, ensuring accurate translation lookup and functionality.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147
This update addresses a potential issue where automated email verification services (Mail Defender) could inadvertently trigger appointment cancellations. The system has been updated to replace direct links with a form, preventing these bots from interacting with the appointment functionality. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#111879 Forward-Port-Of: odoo/enterprise#79831