Monday, April 13, 2026
7 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where spreadsheet pivots were crashing due to incorrect field type support. The team corrected the logic to accurately identify unsupported field types (like JSON) and added comprehensive testing to ensure stability across all field types. This enhances the reliability of the spreadsheet feature for users.
Original PR description
Spreadsheet pivots only do not support all field types. But we were relying only on `field.groupable` to determine if a field could be grouped, which is wrong (eg. JSON fields can be groupable but are not supported). It leads to crashes for fields that were groupable, but didn't have an entry in `pivotNormalizationValueRegistry`. Added a test for all of the field types to ensure we have a correct behavior. Task: 6036075 Task: [6036075](https://www.odoo.com/odoo/2328/tasks/6036075) 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#255571
This update fixes an issue where product names on invoices weren't always displayed in the correct language when using child contacts. The change ensures that invoice line labels are translated based on the language of the selected invoice contact, regardless of the parent contact's language. This improves accuracy and consistency for multilingual invoicing.
Original PR description
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not…
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language. ### Steps to reproduce the issue: 1. Activate at least 2 languages (X and Y) 2. Create a product and set the translation for that product in the activated languages 3. Create a Contact with the language X 4. Create a child contact (invoice adress type) for that contact with language Y 5. Create a new invoice setting the customer as the child contact 6. Add the product you created 7. See the label is displayed in the language of the parent contact ### Cause of the issue: The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language. ### Reason to introduce the fix: To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner. opw-5955875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258458 Forward-Port-Of: odoo/odoo#254833
This update fixes an issue where the event ticket download button wasn't appearing for online payments. The fix ensures that necessary data is always set, regardless of the order's status, allowing the button to display correctly and the confirmation email to be sent as expected. This improves the user experience for customers using online payment methods.
Original PR description
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and…
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and pay with the online payment method - Once on the ticket screen, the button to download the event tickets is not displayed **Why the fix:** The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration. The problem is that with an online payment method, once we enter the **read_pos_data** method that sets the values for the frontend, the order is still in draft, so we just return without doing anything. We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment. In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed. A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed. opw-5438432 Forward-Port-Of: odoo/odoo#249306
This update ensures that negative discount values are displayed correctly in both the Sale Order preview (portal view) and the generated PDF reports. Previously, the PDF displayed negative discounts while the portal preview did not, due to a discrepancy in how discounts were checked in the templates. This change aligns the report output with the portal preview for a consistent user experience.
Original PR description
Steps to produce: --- - Install the `Sales` module. - Enable discounts from settings. - Create a Sale Order with a negative discount on an order line. - Preview the Sale Order and click on the view…
Steps to produce: --- - Install the `Sales` module. - Enable discounts from settings. - Create a Sale Order with a negative discount on an order line. - Preview the Sale Order and click on the view details button. Issue: --- - Negative discount values are not shown in the preview (portal view), but they are displayed in the generated PDF. Root cause: --- - At [1], the portal template includes a condition to display discounts only when they are greater than 0, while the report templates lack this check, leading to inconsistent behavior. Solution: --- - Applied the same condition in the report templates to align the PDF output with the portal preview behavior. Before: --- <img width="787" height="136" alt="image" src="https://github.com/user-attachments/assets/d32311be-4aec-4d6f-b905-d5e52f712ba4" /> After: --- <img width="775" height="139" alt="image" src="https://github.com/user-attachments/assets/2614a8ad-dca6-49ca-b720-5c234aa91cf6" /> [1]https://github.com/odoo/odoo/blob/0f463fd247d2f5da79d6ec2b6bec18774f6f600b/addons/sale/views/sale_portal_templates.xml#L539 Enterprise PR: https://github.com/odoo/enterprise/pull/111916 opw-6061568 Forward-Port-Of: odoo/odoo#258614 Forward-Port-Of: odoo/odoo#255735
This update resolves an issue where the FAIA report incorrectly displayed only the first product with a missing internal reference. The change ensures all products with missing internal references are now shown to the customer, improving data accuracy and compliance. This is part of a larger effort to fix the FAIA XML export.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296 Forward-Port-Of: odoo/enterprise#113452
This update resolves an issue where invoice reports were generating incorrect debit and credit totals due to negative amounts. The fix ensures that invoice line amounts are accurately represented, preventing validation errors and improving the reliability of financial reports. This change is part of a larger effort to improve the FAIA XML export.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113316
This update allows users to bypass the billing address requirement when selling event tickets or services, improving the checkout experience for customers like Eventbrite. A new system parameter enables this functionality for event-related sales, aligning with the understanding that tax information should be based on the event location, not the customer's address.
Original PR description
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