Tuesday, September 16, 2025
15 changes · 18.0
Resolved issues and error corrections
Receipts will no longer show a misleading QR code when the Spanish TicketBAI submission fails. This avoids giving customers an invalid code and helps keep point-of-sale receipts accurate after reporting errors.
Original PR description
Currently if the TicketBAI upload fails, a QR code is printed with the value `true`. Steps to reproduce ----- 1. Validate a POS order 2. Have a request exception occur during the TicketBAI post 3. Receipt is printed with an incorrect QR code Issue ----- `get_l10n_es_pos_tbai_qrurl()` returns None if the edi document is not accepted. This is then interpreted as `true` by the client and a QR code is printed. Solution ----- Explicitly return an empty string if the edi document is not accepted.
Duplicate record checks now ignore company differences when a database only uses one company. This lets users find and merge records that were previously missed, reducing cleanup gaps and duplicate data.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#93184
Indian EDI setup checks now happen after an invoice is posted instead of blocking the posting process. This prevents related sales, subscription, or e-commerce workflows from being rolled back, while still allowing users to fix the configuration and retry EDI sending later.
Original PR description
ISSUE:- Previously, the EDI configuration was validated during invoice posting by overriding the check_move_configuration method. If an error was detected, a UserError was raised, leaving the invoice in the draft state. This behavior caused issues in scenarios where invoices were created with incorrect EDI configurations from subscriptions, sales orders, or e-commerce workflows. The invoice rollback due to the error also left the related sales orders in the draft state, disrupting the process. FIX:- The EDI configuration is now validated after the invoice is posted. If there are errors in the configuration, the invoice remains posted, and no UserError is raised. Users can subsequently correct the EDI configuration and retry the EDI sending process without requiring the invoice to be reposted. Task-4330659
The printer interface now handles printer setup errors more gracefully when CUPS cannot add a printer, such as on read-only systems or with invalid printer names. Instead of stopping the service, the error is logged and the printer interface keeps running.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227121
Customers can now sign and pay sales quotes that include recurring subscription options without getting stuck on an endless loading screen. The system automatically assigns an appropriate subscription plan when such an option is added, helping online sales complete smoothly.
Original PR description
To reproduce: ============= 1. on settings enable **Online Payment** 2. create a normal SO with a recurring product as option 3. send the SO to the customer 4. as customer from protal add the option to the SO and click **Sign & Pay** 5. comfirm the signature and pay the SO -> infinite loading Problem: ======== we can't comfirm an SO with a recurring option if the SO doesn't have a plan_id set. Solution: ========= set the plan_id on the SO when adding a recurring option to it, using the first suitable recurring pricing plan defined on the product if any or a random one. opw-5003708
FedEx Home Delivery shipments can now generate return labels without triggering a recipient address error. This ensures residential delivery information is correctly sent to FedEx, reducing failed shipment validation for affected orders.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065 Forward-Port-Of: odoo/enterprise#94463
This pull request bundles several maintenance updates across Odoo, including refreshed translations and fixes for accounting, website search forms, recruitment filters, localization, and HTTP responses. These changes improve reliability in day-to-day workflows and help prevent incorrect tax calculations, broken website forms, and misclassified accounting entries.
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
Subscription sales orders with a fully discounted recurring line now keep the correct invoice status. This prevents orders from incorrectly showing “Nothing to Invoice” when an invoice exists and future invoicing may still be needed.
Original PR description
**Steps to reproduce:** 1-Install the sale_subscription module. 2-Create a Sale Order and choose any recurring plan. 3-In the Sale Order line add subscription product (e.g.,Office Cleaning Service)…
**Steps to reproduce:** 1-Install the sale_subscription module. 2-Create a Sale Order and choose any recurring plan. 3-In the Sale Order line add subscription product (e.g.,Office Cleaning Service) 4-Add the same product again in a new line with a 100% discount. 5-Confirm the order, create an invoice, and confirm it. 6-Go back to the Sale Order → Other Info section: the invoice status is shown as Nothing to Invoice, even though an invoice was already created and another one can still be generated. **Issue:** - The invoice status is incorrectly set to Nothing to Invoice on the Sale Order. **Cause:** https://github.com/odoo/enterprise/blob/486965b5617ff90b1c32be106ef2b538726bedb9/sale_subscription/models/sale_order_line.py#L72-L75 - In sale_subscription, when a line has a 100% discount, its subtotal becomes zero and this code sets the line’s invoice status to no (nothing to invoice). https://github.com/odoo/odoo/blob/ec2614db4df5b3177387a129f6156ee9844fb544/addons/sale/models/sale_order.py#L636-L642 - In sale, the `_compute_invoice_status` method then aggregates this into the Sale Order, resulting in a wrong invoice status. **Solution:** - Add an extra condition in sale_subscription to properly detect future_line and prevent zero-subtotal lines with 100% discount from incorrectly setting the Sale Order status to Nothing to Invoice. opw - 4999495
Users can now log timesheets on projects shared across multiple companies without seeing an incorrect validation error. This helps employees who work in multi-company environments record their time reliably, even when a project is not tied to one specific company.
Original PR description
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without…
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes **False**. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223846
The appointment booking page now shows the right number of available places when appointments can use multiple resources with different capacities. This prevents customers from being limited by the first resource listed and helps businesses make full use of available appointment capacity.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393 Forward-Port-Of: odoo/enterprise#84243
Subscription invoices that include combo products can now be created and confirmed without errors. This prevents failed billing during manual invoicing or automatic payment processing, reducing disruption for recurring revenue workflows.
Original PR description
Currently, an error is produced while creating an invoice for a subscription order with combo products, and it can be triggered in two different ways. 1. Directly create an invoice. - Create and…
Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.
1. Directly create an invoice.
- Create and confirm a subscription with a combo product.
- Create an invoice for this subscription and try to confirm it.
- Validation error shown in display and error generated in log
2. When cron "Payment: Post-process transactions" trigger:
- Enable the Automatic Invoice option in the Subscription settings.
- Activate a demo payment provider (e.g. Demo: Payment Provider).
- Create and confirm a subscription that includes a combo product.
- Click on "Pay" to process the subscription payment.
- An error occurs when the above-mentioned cron is triggered, and it
tries to create an invoice for a subscription order.
Error: `new row for relation "account_move_line" violates check constraint
"account_move_line_check_accountable_....`
This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`
This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].
[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309
sentry-6763423503Generating PDF quotations for multiple sales orders now skips orders that cannot produce a valid PDF instead of crashing. This helps sales teams print batches of quotations even when one selected order has missing or incomplete information.
Original PR description
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises…
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail. Current behavior before PR: Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data. Desired behavior after PR is merged: After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PDF reports for vendor bills and expense sheets now correctly handle attachments stored as web links or in cloud storage. This prevents report generation errors and helps users include remote supporting documents without manual downloads.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Follow-up PDF reports can now include attachments stored as remote URLs or in cloud storage without failing. This prevents report generation errors and helps users reliably produce customer follow-up documents regardless of where files are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638
This fix prevents certain business-critical attachments from being moved to cloud storage when those attachments are needed directly by Odoo processes such as invoices or expense reports. This helps ensure reports and workflows that rely on attachment data continue to work reliably.
Original PR description
some models use attachments for data for business logics for example, ``account_move.message_main_attachment_id.datas`` ``hr_expense_sheet`` will use all bounded attachments to generate report This commit prevents uploading attachments to cloud storage for some models if they ``_inherit`` or ``_inherits`` model ``mail.thread.main.attachment`` This PR is also a supplement for https://github.com/odoo/odoo/pull/226094 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