Daily updates from Odoo
Wednesday, March 25, 2026
16 changes · 17.0
Resolved issues and error corrections
This update resolves a bug where portal users received blank or incomplete PDFs when printing knowledge articles. The fix ensures the necessary printing styles are loaded automatically, regardless of the print method (Ctrl+P or export), improving the user experience for all portal users. This change enhances the usability of our knowledge base.
Original PR description
Steps to reproduce ================== 1. Log in as an admin. 2. Go to any article and share with the portal. 3. Log in as a portal. 4. Open the shared article. 5. Press `Ctrl + P` or export from…
Steps to reproduce ================== 1. Log in as an admin. 2. Go to any article and share with the portal. 3. Log in as a portal. 4. Open the shared article. 5. Press `Ctrl + P` or export from topbar. Results showing `Export` and `Ctrl + P` works for which users: | Version | Export | Ctrl + P | | ------- | ------------- | ------------- | | 17.0 | Admin, Portal | None | | 18.0 | Admin | None | | 18.2 | Admin | Admin | | 18.3 | Admin | Admin, Public | | 18.4 | Admin | Admin, Public | | Master | Admin | Admin, Public | Technical ========= In 17.0, `Ctrl + P` printed blank PDF because the required style assets `knowledge.assets_knowledge_print` was loaded only on clicking `Export` button. From 18.0, this asset was moved to the bundle `web.assets_web_print` to use style for printing. Though this bundle is not loaded for portal and public users. Note: For all versions, public users got the incomplete PDF on pressing `Ctrl + P`. After this commit, we will load this asset bundle before printing. Task-4797552
This update ensures that reports display decimal numbers using the correct format based on the user's language settings (e.g., comma instead of a dot). Previously, the system always used a dot, which could lead to confusion for users in different regions. This change improves the user experience and data clarity.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533
This update resolves an issue preventing web push notifications from functioning correctly in Firefox. The fix involved switching to a compatible import method for Firebase libraries, addressing a technical incompatibility that was blocking notification delivery.
Original PR description
Currently, web push notifications do not work on Firefox. ### Steps to reproduce * Install `social_push_notifications`. * In the settings, enable and set up web push notifications. * Go to the website and wait a few seconds. A small window will open, asking if you want to allow notifications. * Click "Allow," and another window will open. * Click "Allow" again. You will be met with a traceback. ### Cause The service worker imports Firebase libraries using ECMAScript module imports, which Firefox does not support in service workers. Additionally, one of the Firebase modules itself contains an ECMAScript import, making it unusable in this context. ### Fix * Use `importScripts` instead of ECMAScript module imports. * Use the compatibility version of the Firebase libraries to avoid ECMAScript imports inside the libs themselves opw-4629623 opw-4551502
This update corrects a previous issue where partner totals were incorrectly hidden, regardless of their value. Now, the report accurately displays all partners with totals exceeding €3,005.06, and it properly accounts for sales and purchase journal amounts for insurance operations, ensuring more accurate tax reporting in Spain.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023
This update resolves an issue causing instability in the stable release of Odoo. The change reverts a previous update that was incorrectly using invoice names instead of the correct tax invoice labels in test reports. This ensures accurate reporting and stability for our users.
Original PR description
This reverts commit 8bd288516ce84a2c491dd19bc4527c8ce40a903e as it causes some unexpected behaviour in stable. We'll instead do it in master
This update resolves an issue preventing SBR tax reports from being submitted due to incorrect date formatting and overly long consultant descriptions. The commit restores the original date format and simplifies the consultant name to ensure compliance with validation requirements, allowing reports to pass successfully.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111817
This update resolves an issue where only certain users could delete work entry types within the payroll module. The change now allows SUPERUSER administrators to delete these entry types, streamlining payroll management and reducing administrative overhead. This ensures consistent access for critical operational tasks.
This update ensures that bounce emails sent through the system are translated into the recipient's preferred language, if available. Previously, all bounce emails were displayed in the default system language, regardless of the sender's language settings. This improves communication and clarity for users.
Original PR description
Currently, when an email is sent directly to the catchall, it bounces as expected. However, the bounce email is always sent in the system's default language, even when the sender's email is linked to a partner with a known language preference. This commit ensures that the bounce email is translated into the partner's preferred language when available. If no language is set for the partner, the default system language is used. opw-4085880
This update significantly speeds up the creation of purchase orders by optimizing how the system retrieves stock lot information. Previously, a slow process triggered separate database queries for each lot, but this change consolidates the search, reducing processing time from 27 seconds to just 7 seconds. This improvement impacts the efficiency of our inventory management.
Original PR description
### Description of the issue/feature this PR addresses: We optimize the retrieval of stock move lines by resolving a classic N+1 query bottleneck. In the previous implementation, the system performed…
### Description of the issue/feature this PR addresses: We optimize the retrieval of stock move lines by resolving a classic N+1 query bottleneck. In the previous implementation, the system performed a database search for every individual lot in the recordset. This refactor backports the batch processing pattern to fetch all necessary data in a single query, significantly improving performance for large data batches. This PR goes beyond just backporting the V18/19 logic by using python set logic instead of recordsets to ensure that that grouping logic remains O(n) ### Current behavior before PR: The system uses a nested search pattern within a loop. A separate database request is triggered for every lot in the recordset. Performance degrades linearly as the number of lots increases, leading to slow processing times for large batches. ### Desired behavior after PR is merged: Logic is refactored into a single batch search on stock.move.line. Database overhead is reduced to a constant number of queries regardless of the recordset size. A defaultdict of python sets is utilized to map findings back to their respective lots. ### Benchmarks Profiling creation of purchase orders. Database has ~4200 stock.lot records. | Before | After | |---|---| | 27sec | 7sec | ### References opw-5453842 Backported from: 99b39b72c7e65e85af6f06dcb6b02867623f3f69 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue causing incorrect tax calculations on invoices. The previous change was reverted to ensure stability in the standard Odoo version. The fix will be implemented in the main development branch.
Original PR description
This reverts commit 8b05f7f4c7b85ad2066399bdd0277f6adfabc916 as it causes some unexpected behaviour in stable. We'll instead do it in master
This update ensures that employees are automatically checked out of the system when they are archived. Previously, archived employees remained checked in, which created inconsistencies. Now, the system will automatically record a checkout time when an employee is archived while currently checked in, streamlining the process and improving data accuracy.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes Odoo's testing process by proactively generating bundled resources instead of creating them on the fly. This change speeds up test execution times, leading to faster development cycles and quicker identification of issues. It addresses a performance bottleneck related to lazy-loaded bundles.
Original PR description
tl;dr: look for lazy loaded bundles and add them to the bundles' list to pregenerate before running tests to avoid generation on the fly.
This update resolves an issue where the Chrome debug log file wasn't consistently created, potentially causing problems with Odoo's performance monitoring. The change ensures Odoo correctly handles situations where the log file might be missing, improving stability and troubleshooting capabilities. This is a follow-up to a previous fix.
Original PR description
Follow up to #255054 [Apparently][] on old versions of chrome `chrome_debug.log` may not exist if the verbosity is not at least 1 (or chrome otherwise has had things to write to the log). Thus handle the possibility of the file being missing instead of assuming it's present just because we've told chrome to generate one. [Apparently]: https://github.com/odoo/odoo/pull/255054#pullrequestreview-4001460518 Forward-Port-Of: odoo/odoo#255736
This update resolves an issue where the 'mail.catchall.domain.allowed' system parameter wasn't being properly sanitized when manually configured. This prevented correct domain matching, potentially leading to email delivery problems. The fix ensures all domain entries are correctly processed, improving email functionality.
Original PR description
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But…
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call. This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com" The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match. Before this fix: Create new record in System parameters with key = "mail.catchall.domain.allowed" value = "domain1.com, domain2.com,domain3.com" -> after save, value == "domain1.com, domain2.com,domain3.com" After this fix: -> after save, value == "domain1.com,domain2.com,domain3.com" OPW-5505414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where zero-rated and exempt taxes in Saudi Arabia were not properly reflected in invoices. The changes ensure invoices comply with ZATCA standards and accurately represent VAT status, preventing misleading data. This improves compliance and data accuracy.
Original PR description
Issue: - The field `l10n_sa_exemption_reason_code` was not mapped for zero-rated, zero-rated export, and exempt taxes. - As a result, invoices using 0% taxes incorrectly showed "Not subject to VAT" in the XML, which misrepresented the actual nature of the supply. Imp: - Added new zero-rated and exempt taxes with proper ZATCA/UN CEFACT codes. - Kept legacy 0% taxes unchanged for backward compatibility. - Added Invoice Legal notes to make exemption reason visible in pdf also. - Improved error spacing and removed redundant comma text. Impact: - Ensures full compliance with ZATCA XML standards. - Prevents misleading VAT data representation. Backport of https://github.com/odoo/odoo/pull/234096 taskID-5494997
This update corrects a visual discrepancy in emails generated from the web editor. Previously, `s_numbers` snippet columns didn't stretch to match the tallest column in the email preview. This fix ensures that all columns in sent emails display correctly, maintaining a consistent and professional appearance.
Original PR description
Problem: `s_numbers` snippet columns do not stretch to match the tallest column in the received email, while the editor preview renders them correctly. Cause: The `div.row` is missing `d-flex` and `align-items-stretch` classes, which are required for equal-height columns in the sent email. These classes are already present in the `s_three_columns` snippet. Fix: Add `d-flex` and `align-items-stretch` to the `div.row` at sending time via `fixSNumbersSnippet`. Steps to reproduce: - Drop `s_numbers` snippet. - Add text to one column so it is taller than the others. - Send the email. - Observe columns in the received email only fitting their own content. opw-6044725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255278