Daily updates from Odoo
Tuesday, September 16, 2025
29 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
Budget report entries are now limited to the companies a user is allowed to access. This prevents users from seeing budget-related records from other companies and avoids access errors when opening report lines.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Budget Management" - Go to "Accounting / Accounting / Analytic Budget" - Create a budget - Open the budget - Create a bill (or invoice depending on the budget type) using the analytic used in the budget lines - Create a budget from another company and also a bill using the analytic used in the budget lines - Connect with a user with Accounting rights who only has access to the first company - Go to "Accounting / Reporting / Management / Budget Report" - Switch to the list view - Remove the "Open Budget" filter **Issue:** The entries linked to the budget from the other company are visible. When trying to open one of them, an access error is raised. **Solution:** Add a multi-company record rule for budget report. opw-4943360
The portal signature form now checks whether a pop-up window is present before trying to use it. This prevents an error when the form is placed directly on a page, allowing customers to complete signatures in more contexts.
Original PR description
Description of the issue/feature this PR addresses: Be able to use the portal signature form outside of a modal. Current behavior before PR: If the signature form (```<t t-call=“portal.signature_form”>```) is used outside of a modal, an error occurs: ```TypeError: Cannot read properties of null (reading 'addEventListener')``` Desired behavior after PR is merged: The signature form can be used outside of a modal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224564
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
Renamed spreadsheets now keep their updated name when users create a new file and navigate back through the breadcrumb. This prevents confusion where a previously named spreadsheet appeared as untitled.
Original PR description
Steps to reproduce: - Create a spreadsheet - Rename it to "My awesome spreadsheet" - Click on File -> New - Go back to "My awesome spreadsheet" from the breadcrumb => The spreadsheet is untitled. This was caused by the fact that the name was not saved in the local state of the action. Task: 4942117
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
Performance tests were adjusted so they no longer fail when timing results vary unpredictably. This makes automated checks more reliable and avoids blocking work because of inconsistent test timing rather than real product issues.
Original PR description
These tests are non-deterministic, we should not fail when running them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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-6763423503Saudi e-invoices for foreign customers now format the Other Buyer ID as an alphanumeric value required by ZATCA. This helps avoid acceptance warnings during invoice submission and improves compliance with Saudi e-invoicing rules.
Original PR description
When an invoice is being issued to a Foreign Customer, the Other Buyer ID (Other Buyer ID (BT-46) <cac:AccountingCustomerParty / cac:Party / cac:PartyIdentification / cbc:ID>) should be OTH and filled accordingly to avoid an acceptance warning from ZATCA. According to ZATCA, the value needs to be in alphanumeric format, even if the value does not follow the specific country's VAT format Task-id: 5075005 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#226593
Swiss ISO20022 payment files are now generated in a format accepted by Swiss banks again. This helps businesses avoid rejected vendor payment batches and reduces manual payment processing delays.
Original PR description
Since July, the iso20022 payment method is to not be accepted by some Swiss banks anymore. How to reproduce? Install account_iso20022 and enable batch payments in the accounting settings. Configure your journal adding the payment method "Swiss ISO20022" in the outgoing payments and setting the XML format as "pain.001.001.09". Pay a vendor bill using the "Swiss ISO20022" payment method. Go to the journal payment, select the previous payment and create a batch. On the batch payment, you can find the XML file which is not validated by Swiss banks. test validation on: https://ubs-paymentstandards.ch/login opw-4976852 opw-4675667 opw-4996910 opw-4895258 opw-5006895 task-id: 5000729
Generating 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
This fix prevents Odoo's internal test and diagnostic tools from failing again while handling an existing serious error. It helps preserve the original failure details, making troubleshooting more reliable when screenshots or screencasts are attempted after a crash.
Original PR description
Cf #226267 the "error condition" on the ws socket is that it's not present at all, not that it's `None`. So when used after a fatal error (e.g. in the context of trying to take a screenshot or take a screencast) these methods *can* in some cases trigger a compound failure and lose the original error because they fail on trying to access the ws to check if it's truthy. Forward-Port-Of: odoo/odoo#227385
Users can now drag and drop Font Awesome icons in the HTML editor without triggering an error. This improves editing reliability and prevents an interruption during content creation.
Original PR description
**Current behavior before PR:** Dragging and dropping a `fa` icon leads to traceback. This issue happens because in onDrop method, value of `htmlTransferItem` contains only a ZWS wrapped in a `<span>`. This span gets removed in `prepareClipboardData`, alongwith ZWS resulting in an empty fragment being passed to the `insert` method. The insertion of an empty fragment lead to the traceback. **Desired behavior after PR is merged:** Now, `fa` icon can be dragged and dropped without a traceback. task-4882121 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes automated checks for Saudi and GCC point-of-sale localization so they run reliably in single-app test environments. It helps maintain confidence that localized point-of-sale flows continue to work correctly without affecting day-to-day users.
Original PR description
Fix runbot error in single app runbot-231469 runbot-231471
Fixed an issue that caused an error when opening the barcode scanner in Attendance kiosk mode while debug mode was enabled. This helps administrators and support teams use and troubleshoot the attendance scanner without interruptions.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- 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
This fix prevents an installation error when the withholding tax module is installed alongside Indian localization demo data. It makes the setup more reliable by only using purchase taxes that include the needed tax distribution details.
Original PR description
Traceback when no `repartition_line_ids` found in tax data. Steps to reproduce:- - Install `l10n_in` module with demo data. - Install `l10n_account_withholding_tax` module. Error:- ``` File /data/build/odoo/addons/l10n_account_withholding_tax/__init__.py, line 27, in _make_demo_tax tax_repartition_lines = [line[2] for line in tax_data[purchase_taxes[0]]['repartition_line_ids'] if line[2]['repartition_type'] == 'tax'] KeyError: 'repartition_line_ids' ``` Root Cause: At [1], No `repartition_line_ids` found in `tax_data[purchase_taxes[0]]`. Solution: Select only purchase taxes having `repartition_line_ids`. [1]: https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/l10n_account_withholding_tax/__init__.py#L27
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
The Malaysian EDI forms now show identity card number placeholders without hyphens. This avoids misleading users and helps company and contact details pass validation with the IAP server and MyInvois.
Original PR description
Hyphens are generally omitted in ERPs, and just shown on the Identity card. Putting hyphens in the placeholder is actually misleading for users, and prevents validation through the IAP server and MyInvois Ref: https://en.wikipedia.org/wiki/Malaysian_identity_card#Structure_of_the_National_Registration_Identity_Card_Number_(NRIC) Task [link](https://www.odoo.com/odoo/project/967/tasks/5054821) task-5054821
Documentation and clarification updates
This pull request updates Quartile's corporate Contributor License Agreement documentation. It keeps Odoo's contributor legal records current and confirms the contributor has followed the required submission process.
Original PR description
@qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226204
This pull request updates Odoo's contributor agreement documentation by adding a contributor under Ahkio Consulting. It helps keep legal contribution records accurate and up to date, with no impact on product functionality.
Original PR description
Description of the issue/feature this PR addresses: Add a contributor to ahkio-consulting.md --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr