Thursday, May 14, 2026
14 changes · saas-18.3
Resolved issues and error corrections
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and improving performance. It also addresses a memory leak in the PDF processing, leading to faster report creation, especially with large documents. The change results in significantly smaller PDF files and faster print times.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#264355 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF document generation by compressing files after merging, reducing their size significantly. It also addresses a memory issue in the PDF processing, leading to faster performance, especially with large documents. The result is smaller, more efficient PDF files.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117254 Forward-Port-Of: odoo/enterprise#115550
This update fixes an issue where discount lines in Czech VAT reports were incorrectly calculating values. The previous method applied an absolute value function, leading to inflated report totals. The fix now correctly handles negative discount amounts, ensuring accurate VAT reporting.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087
A recent test for point-of-sale receipt generation was failing due to an overly broad selector used to identify the shipping date. This update added a specific class to the shipping date element, ensuring the test accurately reflects how the receipt is generated across different localization settings. This resolves a potential issue with receipt accuracy.
Original PR description
Issue: ====== - The test used the selector `.pos-receipt-order-data div` to retrieve the shipping date. - This selector is not specific and matches different elements depending on localization. Fix: ==== - Add a specific class `shipping-date` to the shipping date element and update the test to use `.pos-receipt-order-data .shipping-date` to avoid incorrect matches. Task-6183114 Error-241995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262761
This update resolves an issue where the color picker wasn't available when editing website snippets with images containing shapes. The fix ensures that users can now customize the colors of these images directly within the website editor, improving design flexibility. This change impacts the website editing experience.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#246249
The 'Load More' feature in the journal report was repeatedly loading the same data due to a technical issue. This update correctly implemented pagination, ensuring that the report only displays the necessary data based on the user's selection, improving performance and accuracy.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082 Forward-Port-Of: odoo/enterprise#116367
This update fixes a limitation in how Odoo handles attachments uploaded through cron jobs. Previously, a single cron job could only upload one attachment at a time. Now, attachments can be uploaded in bulk, improving efficiency for automated processes. This change ensures smoother and faster uploads for scheduled tasks.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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 Forward-Port-Of: odoo/odoo#264328
This update fixes a potential crash during bank statement imports by ensuring the correct journal is selected. The system now validates currency and IBAN matches, automatically finding the appropriate journal if a mismatch exists. This prevents errors and improves the reliability of importing bank statements.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037
Forward-Port-Of: odoo/enterprise#116860
Forward-Port-Of: odoo/enterprise#115475This update resolves a technical issue causing malformed XML in the TestReports module. Previously, automatic cleanup handled this, but with newer software, the fix ensures accurate test reporting and prevents potential errors. This change improves the reliability of our testing processes.
Original PR description
This commit fixes a malformed HTML/XML tag in TestReports. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Note: backport of https://github.com/odoo/odoo/pull/258569 Forward-Port-Of: odoo/odoo#264330
This update addresses an issue where gift card balances automatically confirmed sales orders, bypassing the final checkout step. Now, Odoo will only confirm sales when a customer completes the standard checkout process, even with a fully covered cart. This ensures a more reliable and secure purchase experience.
Original PR description
**Before this commit** If a gift card balance fully covers a shopping cart containing multiple events, Odoo auto-confirms the order as soon as the last event is added, skipping the final checkout step. **After this commit** Sale orders will no longer be automatically confirmed when a customer registers for a paid event, even if an applied gift card brings the total balance to zero. opw-5896626 Forward-Port-Of: odoo/odoo#264233 Forward-Port-Of: odoo/odoo#246629
This change resolves a bug that caused invoices to fail when using the 'biggest tax' cash rounding strategy with customer addresses enabled. The fix ensures the correct partner ID is used during invoice processing, preventing data deletion and ensuring accurate calculations.
Original PR description
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759
This update resolves an issue where users could create attachments that pointed back to themselves, leading to errors. The fix prevents attachments from being linked to themselves in both the user interface and during data writing, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
This update adjusts how global discounts are exported to align with UBL (Universal Business Language) specifications. Previously, discounts were handled as negative invoice lines, which is now corrected to use 'allowances' for accurate UBL compliance. This ensures our accounting system meets international standards for electronic invoicing.
Original PR description
…ances Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 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 a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Specifically, it corrects rounding errors that occurred when invoices with many items had small negative line discounts, leading to validation failures. This ensures invoices meet SAT requirements and avoids potential payment processing problems.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297