Daily updates from Odoo
Thursday, May 14, 2026
115 changes
5 changes
Resolved issues and error corrections
This update fixes a previous issue where the closing popup for bank payments didn't accurately display the number of payments made. Now, the popup correctly shows the total count of payments associated with a bank method, reducing user confusion and improving the clarity of payment information. This enhancement ensures users have a complete understanding of their transactions.
Original PR description
Before this commit, in the closing popup if a bank payment method had more than one payment, it would not show the count of payments, which could lead to confusion for the user. opw-6198656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263234
This update fixes an issue where large tablets with touch capabilities incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a heading tag within a selection didn't properly remove the original heading style. The fix utilizes a different function within the HTML editor to ensure heading styles are accurately reset when a tag is modified, improving the consistency of formatting.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
This update resolves an issue that prevented invoices with combo products lacking taxes from being processed correctly when generating Peru UBL invoices. The fix ensures that combo product lines without taxes are properly validated, preventing a traceback and ensuring successful invoice generation. This improves the reliability of the Peru UBL integration.
Original PR description
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data -…
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data - Switch to PE Company - Create an invoice > Add a Office Combo product > unset the taxes > Confirm - Process now https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552 Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line. Normally, invoices without taxes are restricted at [1], but combo products are excluded from this validation at [2]. As a result, combo product lines without taxes bypass the restriction and trigger a traceback. [1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929 [2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434 sentry-7430552834 Forward-Port-Of: odoo/enterprise#117365 Forward-Port-Of: odoo/enterprise#114798
This update fixes an issue where UBL invoices could incorrectly apply taxes due to differences in fiscal positions. The change ensures that only taxes matching the invoice's fiscal position are used during import, improving the accuracy of financial data. This prevents errors related to tax calculations and reporting.
Original PR description
When importing a UBL invoice, multiple taxes may share the same rate (e.g. 21%) but differ by fiscal position. Without filtering, the wrong tax (e.g. the domestic one for a foreign partner) could be selected. task-6138749 Forward-Port-Of: odoo/odoo#264597 Forward-Port-Of: odoo/odoo#263872
6 changes
Resolved issues and error corrections
This update resolves a problem that occurred when creating consolidated POS invoices from multiple orders for the same customer. The previous issue caused errors due to how refund reasons were being handled across multiple orders. Now, the system safely collects and validates refund reason values, ensuring invoices are created correctly and preventing potential errors.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where completion and refusal emails for signatures were incorrectly using the signer's partner email instead of the correct, validated email defined for the sign request. Now, emails sent to signers will use the accurate email address, ensuring proper communication and notification delivery. This improves the reliability of the signature process.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from 'Header 2' to 'Header 1') didn't fully remove the previous heading style. The fix ensures that selected text correctly loses its original heading formatting, improving the accuracy of text editing within Odoo.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. It addresses a previous memory leak and leverages newer pypdf versions for better performance, particularly with large reports. The result is faster report generation and reduced storage needs.
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#264451 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF generation by compressing files after merging, resulting in significantly smaller file sizes and faster processing times. It addresses a previous memory leak issue and leverages newer PDF library versions for better efficiency, particularly when handling large documents. This improves user experience and reduces storage needs.
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#117308 Forward-Port-Of: odoo/enterprise#115550
3 changes
Resolved issues and error corrections
This update resolves a problem that occurred when creating consolidated invoices from multiple POS orders for the same customer. The fix ensures that all refund reason values are correctly collected and validated, preventing errors and maintaining data consistency. This improves the reliability of invoice generation for multi-order transactions.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop version. The change now considers screen size alongside touch capability, ensuring the correct toolbar is shown on all devices. This improves the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from H2 to H1) didn't properly remove the previous heading style. The fix ensures that selected text now correctly loses its original heading formatting, improving the consistency and accuracy of text editing within the Odoo website.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
1 change
Resolved issues and error corrections
This update fixes an error that prevented credit notes from being successfully submitted for invoices sent to jofatora. The issue stemmed from a mismatch in customer information between the credit note and the original invoice. This ensures proper invoice processing and submission.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573