Daily updates from Odoo
Tuesday, April 14, 2026
14 changes · 17.0
Resolved issues and error corrections
This update fixes an error in how Odoo calculates depreciation for assets with shortened fiscal years. Previously, entries were skipped during certain months, leading to inaccurate depreciation reporting. The fix ensures that depreciation calculations align with the correct fiscal year boundaries, improving financial accuracy.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834
This update corrects a recent issue with accounting dates used in payroll journal entries. It reverts a previous change that was causing inaccuracies in financial reporting. This ensures payroll accounting aligns correctly with company financial records.
Original PR description
This reverts commit 01717c6fdb6bbbc3149048f6284807c7fc36f540. Task: 6116315
This update fixes a security issue where unauthorized users could access asset information within invoices. The change restricts access to the `account.asset` model to users within specific accounting groups, preventing accidental or malicious data access. This ensures data integrity and protects financial records.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#112890
This update resolves an issue preventing correct invoice report naming in the Mexican tax module (l10n_mx_edi). It aligns with a recent community update, ensuring compatibility and preventing errors during invoice sending. This improves the reliability of invoice processing.
Original PR description
Update _get_invoice_report_filename override to accept the optional report parameter and forward it to super(). This is a compatibility fix linked to the community PR, which extends the base helper to support dynamic report naming. Without this update, the enterprise override still uses the old signature and causes errors in invoice send flows. This change ensures compatibility with the updated helper in account and prevents errors in invoice send flows when a report is provided. Related Community PR: https://github.com/odoo/odoo/pull/256204 Related Ticket: opw-6058716
This change removes a confusing tooltip from the calendar popover for boolean fields. The tooltip was displaying unnecessary HTML content, creating a poor user experience. This improvement simplifies the calendar interface and enhances usability.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205
This update corrects a visual issue in the product expiry module where all products without removal dates were incorrectly highlighted in red. Now, only products with expired lots/serials or quantities below zero will be flagged as expired, ensuring accurate product tracking and inventory management. This resolves a misleading display that could have impacted decision-making.
Original PR description
**Description of the issue/feature this PR addresses:** Install product_expiry and have products in stock with a quantity greater than 0 and not having any serial or lot configuration. **Current behavior before PR:** All lines which have no valid removal_date set (normally just those which are to be subject to be expired) will be marked red. **Desired behavior after PR is merged:** The tree view is showing as intended only if a product lot/serial is expired or a quantity less than zero will be marked red. Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where printing surveys didn't display participant answers, leading to incomplete reports. The change ensures all survey responses are always included when printing, providing more accurate and reliable data. This improves the quality and consistency of survey results.
Original PR description
Previously, printing surveys of type scoring_without_answers omitted participants' answers, resulting in incomplete and inconsistent reports. This commit ensures answers are always included, regardless of survey type. Task-5407701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258616
This update resolves an issue where tax wasn't correctly applied to sales orders when using fixed amount discounts. Previously, users had to manually set tax on discount products. Now, the system automatically considers tax from the discount product, ensuring accurate tax calculations for all discount scenarios.
Original PR description
Steps to reproduce: - Apply fixed amount discount on sales order. - Go to the discount product which got created and set tax for it. - Again apply fixed amount discount on sales order. Issue: If tax is set for fixed amount discount product, tax is not applied when discount is applied on sales order. Cause: User have to manually set the tax even if he has set tax for fixed amount discount. Fix: Consider the tax from discount product if there is any. opw-3935350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where German hybrid invoices processed through Peppol were failing to correctly identify invoice customizations. The change clarifies how the 'zugferd' format is handled, ensuring it's treated as a distinct format from Peppol EDI, leading to accurate invoice processing.
Original PR description
The 'zugferd' key was missing from the `_get_customization_ids` mapping, causing potential failures when attempting to identify the correct CustomizationID for German hybrid-style invoices being processed through the Peppol exchange. This is because the 'zugferd' format was wrongly considered as peppol edi format, whereas it should behave like the 'facturx' format and be excluded from the peppol edi formats. opw-6009214
This update resolves an issue where a previous manager would continue to receive department messages after a new manager was assigned. Now, when a manager is reassigned, they are automatically unsubscribed from all department communications, ensuring a cleaner and more accurate notification system. This improves the user experience for both managers and department members.
Original PR description
…ager is assigned 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 where an old manager would continue to receive department messages after a new manager was assigned. The change ensures that users are only notified about relevant department communications, improving email efficiency and reducing potential confusion. This is a minor fix impacting the HR module.
Original PR description
…ager is assigned 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 resolves an issue where a previous manager remained listed as a follower after a new manager was assigned. The change ensures that the old manager is automatically unsubscribed from the department, maintaining accurate follower lists and streamlining organizational updates. This improves data accuracy and reduces potential confusion.
Original PR description
Description of the issue/feature this PR addresses: old manager is still in followers after changing Current behavior before PR: old manager is still in followers after changing Desired behavior after PR is merged: old manager gets unsubscribed to the department --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where stock quantities were incorrectly displayed for a company when a purchase order was processed through another company in a multi-company environment. The change ensures stock quantities are restricted to the product's assigned company, preventing errors and improving data accuracy. This resolves a reporting discrepancy.
Original PR description
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company…
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company environment. If a purchase order with product from company 1 is being confirmed, received, and validated when company 2 is being selected as the primary active company while company 1 is also checked. It will create a stock.quant that is searchable for company 2. However, it will raise an error when company 2 is trying to access it. **After this commit:** Even if the stock.quant is created when company 2 is the primary active company, it will not be searchable for company 2 since the product's company is company 1. **Steps to Reproduce on Runbot:** - Create a storable product exclusive to Company A - Create & validate a receipt for that product in Company A. - Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible. opw-6082330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that invoices sent via email now use the custom 'Printed Report Name' configured for reports, rather than a default naming pattern. The change corrects a previous issue where invoice emails incorrectly generated attachments with generic names, leading to potential confusion and misidentification of documents. This improves the clarity and professionalism of invoice communications.
Original PR description
When sending an invoice by email template, the generated PDF attachment does not use the configured Printed Report Name. Instead, it falls back to a default naming pattern (e.g. report action name +…
When sending an invoice by email template, the generated PDF attachment does not use the configured Printed Report Name. Instead, it falls back to a default naming pattern (e.g. report action name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send wizard. In the invoice flow, _get_placeholder_mail_template_dynamic_attachments_data uses the invoice report context instead of the actual dynamic report. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from extra_mail_template. Additionally, _get_invoice_report_filename needs to be extended in 17.0 to optionally accept a report and use its print_report_name like in the newer versions while preserving fallback behavior. The safe_eval is taken from code used in the future version's code, and is needed as the field accepts python expressions. This naming issue occurs from 17.0 to current master, and the fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). Go to Settings > Technical > Email > Templates and open “Invoice: Send my email”. Add the duplicated report under Dynamic Reports. Create a customer invoice and confirm it. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716