Wednesday, June 25, 2025
11 changes · 17.0
Resolved issues and error corrections
Package barcode PDFs now keep package names on one line beneath the barcode. This prevents names with spaces or dashes from wrapping awkwardly, improving label alignment and readability when printing inventory package labels.
Original PR description
<b>Steps to Reproduce:</b> 1. Navigate to Inventory → Configuration 2. Search for packages and check 3. Products → Packages 4. Click or create a Package (With at least 15-20 Char). 5. Print > Package Barcode (PDF) <b>Issue:</b> - Package names containing dashes (e.g., A101-101-110-1910) or spaces (e.g., A192 2932 2039) were breaking, affecting alignment and readability. <b>Solution:</b> - Applied `white-space: nowrap` style to the text span to prevent line wrapping and ensure consistent alignment across all package name formats. <b>opw-4872595</b> Before FIX:  After FIX : 
Field Service users can now resend an individual task report after it has already been sent. This helps teams share updated reports when details change after the first send, without being blocked by the previous button state.
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953
Printing through an IoT Box now keeps the process stable even if a user navigates away quickly. This prevents an error from appearing when a print request is still being completed, improving reliability for daily printing workflows.
Original PR description
When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421
The scheduled payroll data update has been changed to run once a week instead of more frequently. This reduces unnecessary background processing while keeping payroll-related information refreshed on a regular cadence.
WhatsApp template synchronization now recognizes additional language codes officially supported by WhatsApp. This prevents sync failures for businesses using those languages, such as Colombian Spanish.
Original PR description
**Error:** `ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'` **Before:** Some language codes that are officially supported by WhatsApp were missing from the module's language list, leads to an error during template synchronization. **After:** This commit adds missing language codes, which are supported by WhatsApp to prevent errors during synchronization. Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-languages Sentry – 6704097351
Miscellaneous changes
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single
Original PR description
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single record uses `message_post` which calls `_message_set_main_attachment_id`. While in the case of a batch, it is not. Solution -------- Explicitly link `mail.message` attachments to the original `account.payment` record. Similar to what is done for `account.move` attachments that are linked to the `account.move.send` records. OPW-4500389 Forward-Port-Of: odoo/odoo#202345
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_colum
Original PR description
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a…
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_column` is called with superuser privileges, which lack user context. This causes warehouses to always be linked to the superuser's company (id=1). As a result, modifying sales orders from different companies becomes impossible. opw-4735086 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#207792
When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215580
Original PR description
When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215580
Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 --- I confirm I have signed th
Original PR description
Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215523
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places,
Original PR description
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places, the amounts on the entry end up being 0s. task-4714764 Forward-Port-Of: odoo/enterprise#83963
When the fields from the models account.move.line and account.analytic.line have the same name but a different type, a traceback is raised when an analytic filter is set on a report. opw-4769750 Forward-Port-Of: odoo/enterprise#85599
Original PR description
When the fields from the models account.move.line and account.analytic.line have the same name but a different type, a traceback is raised when an analytic filter is set on a report. opw-4769750 Forward-Port-Of: odoo/enterprise#85599