Daily updates from Odoo
Tuesday, March 24, 2026
17 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the SDWorx payroll report wasn't correctly accounting for public holidays. The change ensures that employee attendance is accurately calculated, including days when the company is closed for public holidays, leading to more precise payroll reporting.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
This update fixes a problem where Mexican CFDI invoices generated by our system were missing a crucial piece of information – the ‘numero pediemento’ (import document number). The fix ensures that all CFDI invoices comply with Mexican tax regulations, preventing potential issues with tax authorities. This improves the accuracy and reliability of our invoicing process for Mexican businesses.
Original PR description
The numero pediemento is missing in invoices CFDI Step to reproduce: - in MX company with l10n_mx_edi_landing - create an invoice - add product with a custom number (with 2 spaces between number ranges) - Confirm and send The generated CFDI is missing the `InformacionAduanera` node and its `NumeroPedimento` attribute. Cause: Node and attribute are filled in the CFDI from the 'complementos_list'. Which is a copy of each base_line 'l10n_mx_cfdi_values'. The list was missing the `informacion_aduanera_list`. opw-5949684 Forward-Port-Of: odoo/enterprise#110347
This update fixes an issue where currency rates from the Bulgarian National Bank (BNB) were incorrectly processed, leading to reversed unit-to-EUR and EUR-to-unit calculations. The change adjusts the data parsing process to accurately use the standard 'RATE' value from the XML feed, ensuring correct currency conversions for Bulgarian operations.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update fixes an issue where configuring PEPPOL document sync settings incorrectly directed users to a document form instead of the intended Kanban view. Now, users will correctly see the document Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This ensures a smoother and more intuitive experience for managing PEPPOL documents.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111341
This update corrects a validation error in the Romanian SAFT reports generated by Odoo. The team restored a key data element and used a sanitized bank account number to ensure compliance with Romanian tax regulations and prevent report rejection.
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
This update fixes a misunderstanding regarding the W4 form filing date in the US payroll system. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll calculations and compliance.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
This update fixes an issue in Web Studio where invisible fields weren't consistently hidden based on user access. Previously, toggling the 'Show Invisible Elements' checkbox didn't always retain the intended invisibility settings. The fix ensures that invisible fields remain hidden when the user lacks access, improving the user experience and data consistency within the studio.
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#111299
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing for more flexible leave management. Specifically, it now permits leave creation even when payroll impacts are present, provided certain percentage conditions are met, ensuring accurate leave tracking within the Swiss payroll system. This change improves usability and reduces potential disruptions for HR teams.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111503 Forward-Port-Of: odoo/enterprise#101333
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 data accuracy and 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 prevents the entire reporting cron process from stopping if a single report export fails. Previously, an error would halt all subsequent exports. Now, the cron will continue to attempt sending other reports, improving reliability and ensuring timely report delivery.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves an issue where users without sales permissions were encountering errors when viewing product information within the Odoo interface. The fix allows all users to access product subscription pricing data by bypassing access restrictions, ensuring a smoother experience for all users regardless of their role.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036 Forward-Port-Of: odoo/enterprise#108265
This update resolves an issue preventing invoices with discounts and decimal values (over 2 decimals) from being correctly generated for ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal handling and successful EDI invoice creation.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
This update corrects a small, technical issue with a message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting of payroll information. This change improves the overall quality and reliability of the payroll documentation.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update resolves a bug where users could incorrectly create 'Requested Documents' instead of folders when syncing PEPPOL documents. To avoid further complications with folder placement, the ability to create or edit folders within the settings has been removed, aligning with a previous fix. This ensures accurate PEPPOL document synchronization.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736
This update corrects a bug where dropship orders weren't accurately reflecting delivered quantities. The fix ensures that delivered quantities are correctly calculated when a product is shipped directly from one company to another via a dropship route, resolving a discrepancy of 0 delivered units. This ensures accurate order fulfillment and reporting.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215 Forward-Port-Of: odoo/enterprise#111108
This update addresses a security vulnerability where automated systems (like Mail Defender) could unintentionally cancel or reschedule appointments through links in emails. The system now uses a form instead of a direct link, preventing these automated actions. 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#110795 Forward-Port-Of: odoo/enterprise#79831