Daily updates from Odoo
Friday, October 24, 2025
28 changes · 18.0
Resolved issues and error corrections
This fix prevents an accounting process from failing when it encounters an empty value where a number is expected. It helps users continue their workflow without seeing an unexpected ValueError.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Odoo's Spreadsheet app. It helps users work with spreadsheets more reliably, reducing disruption when using spreadsheet-related views or documents.
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
This update adjusts spreadsheet-related testing assets to correct the reported FRGI testing issue. It helps keep spreadsheet behavior reliable and reduces the risk of test-related regressions affecting future changes.
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
Spreadsheets without a custom thumbnail now show a spreadsheet-specific default image instead of a generic placeholder. This makes document previews clearer and helps users identify spreadsheet files more easily.
Original PR description
## Description Before this fix, when a spreadsheet had no thumbnail, the system displayed the generic web placeholder image (`web/static/img/placeholder.png`). This PR updates the logic to display a more relevant default image specific to spreadsheets (`/spreadsheet/static/img/spreadsheet.svg`) when no thumbnail is available. Task: [4963284](https://www.odoo.com/odoo/project/2328/tasks/4963284)
This update makes automated checks for the two-factor authentication setup flow more dependable by replacing fragile timing-based steps with clearer confirmation points. It reduces intermittent test failures under load, helping teams validate security-related workflows with fewer false alarms.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513
The French FEC import now uses a valid debit account when handling rounding differences. This prevents import issues caused by a chart of accounts change where the previous account code became a grouping account instead of a usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#96972
Failed mass mailing emails are now retried in smaller batches instead of all at once. This helps large campaigns recover after an email server outage without crashing, making resend operations more reliable for high-volume customers.
Original PR description
Steps to reproduce the issue: 1. Have 100s of thousands of recipients on a campaign 2. Disconnect your outgoing server and send 3. Reconnect the mailing server and retry sending. Current behavior before PR: A `MemoryError` is raised due to the large number of emails processed to `unlink()` Desired behavior after PR is merged: Larger-scale clients would be able to resend 100s of thousands of emails if they fail opw-5091567 Forward-Port-Of: odoo/odoo#228446
The Field Service “To Schedule” view now excludes tasks that are already done or cancelled. This keeps teams focused on work that still needs scheduling or assignment and avoids confusion from completed or closed tasks appearing in the list.
Original PR description
**steps to reproduce:** Go to field service Go to all tasks > to schedule **issue:** The To Schedule filter was also displaying tasks in cancelled or done state, whereas it should only show open tasks that need to be scheduled or assigned. **cause:** The filter domain did not exclude cancelled/done state, causing closed tasks to appear in the filtered view. **fix:** Updated the filter domain to exclude cancelled/done state, to ensure only open tasks are shown under the To Schedule filter. task-5138590 Forward-Port-Of: odoo/enterprise#96600
Imported Italian supplier bills no longer apply the same discount twice when the XML contains both a discount section and a matching negative line. This helps keep bill totals accurate and avoids manual corrections after import.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335) Forward-Port-Of: odoo/odoo#225044
This fix ensures landscape PDF reports print in the correct orientation when sent through a Virtual IoT Box. It prevents pages from being printed as portrait and cropped, helping users get complete, properly formatted printed reports.
Original PR description
When printing a landscape report using a Virtual IoT Box, we end up printing a portrait page cropped. This commit adds the "pdf fit page" argument to ensure the page printed follows the report orientation. opw-5051809 Task: 5149706 Forward-Port-Of: odoo/odoo#232866
Fixes a problem where Spanish VeriFactu credit note errors could stop the automatic invoice sending task, preventing other invoices from being sent. Affected credit notes are now reported as errors while valid documents continue through the normal sending process.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#230762
This fixes an issue where users could accidentally clear a drawn signature while still in the middle of drawing, yet the document would still allow signing. The signature flow now avoids that accidental clearing so users cannot submit a blank signature by mistake.
Original PR description
To reproduce: ============= - upload a doc, add a signature field, sign now, open the signature wizard - go in draw mode - draw something - erase - draw something, keep the click on and go outside the box - press enter, this will remove the content - release the click --> box is blank and "sign" and "sign all" buttons are available and can sign the doc. Problem: ======== when clearing while drawing, the listner for mousedown is still active and when releasing the click outside the box, it triggers the mouseup event which makes `isEmpty=false` and enables the sign button. Solution: ========= don't allow clearing while drawing. opw-5071981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps Colombian DIAN electronic invoices aligned with local reporting requirements after a related platform change. It removes an extra tax currency field from the DIAN XML because tax amounts are already reported in Colombian pesos and currency conversion details are covered elsewhere.
Original PR description
In the related community PR we added the `TaxCurrencyCode` node for the (generic) UBL format. To avoid modifying the DIAN XML generation we remove this node / information here. In DIAN all the tax information is given in COP anyway and there are the `SourceCurrencyCode` and `TargetCurrencyCode` to cover all the currency information. task-4885680
Fixed an issue where internal users clicking "View Product" from a product email were sent to the general shop page instead of the product’s internal page. This ensures staff with the right access land in the correct place, while public and portal users continue to use the website product page.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281
Users whose contact record is linked to multiple user accounts can now create spreadsheets from the Documents app without hitting an error. This prevents an unexpected blockage in the normal document creation flow for organizations with merged or shared contact records.
Original PR description
Before this commit: 1. connect with a user, the partner_id of which is linked to multiple users via the user_ids field (this can be done by manually setting it, or by merging contacts, for example) 2. go to the Documents app, click new, then spreadsheet --> expected singleton Traceback opw-5133850
Invoices sent to Spain's TicketBAI system are now ordered by posting chronology before their chain numbers are assigned. This prevents batches from being numbered backwards, helping businesses keep legally required invoice sequences accurate.
Original PR description
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list…
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list view, select them and send to TicketBAI. 5) The TicketBAI “chain index” is inverted: the newest invoice gets the smallest index and the oldest gets the largest. The first invoice in the legal/chronological sequence is not index 1. Current behavior: - When sending multiple invoices at once, the processing loop uses the batch order as-is, which (from the list view) often arrives in reverse chronological order. The chain index is assigned incrementally based on that order, yielding an inverted chain (newest=1, oldest=N). Expected behavior: - The TicketBAI chain index must follow issuance/confirmation chronology: the oldest posted invoice in the batch is index 1, then 2, … up to the newest. Technical reason: - `_call_web_service_before_invoice_pdf_render` iterates `invoices_data.items()` without an explicit ordering by confirmation (posting) date. Depending on how the selection is built, items are processed newest-first, so the computed `chain_index` is reversed. Solution: - Sort the invoices before sending by posting date (`move.date`) ascending, with fallbacks to `invoice_date` and `create_date`, and a deterministic tiebreaker by `id`. Process sequentially after sorting and keep the per-invoice commit. opw-[5072667](https://www.odoo.com/odoo/my-tasks/5072667) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Cambodian localization data was corrected so tax names are no longer duplicated. This prevents errors when companies manually install the Cambodian chart of accounts, making setup more reliable.
Original PR description
Fixes an issue where some taxes in the Cambodian package have the same name, leading to errors when manually installing the chart template. Interestingly enough, the constraints does not trigger on the demo data company. Task [link](https://www.odoo.com/odoo/project.task/5194444) task-5194444
Point of Sale users now see a clear message when searching orders with an unsupported long tracking number instead of encountering a system traceback. This prevents confusion and makes the limitation easier to understand when using the Orders search.
Original PR description
**Steps to reproduce:** - Go to PoS>Orders - Search by Order Number and input at least 4 characters - A traceback will appear **Why the fix:** In 18.0, we do not support long search for the…
**Steps to reproduce:** - Go to PoS>Orders - Search by Order Number and input at least 4 characters - A traceback will appear **Why the fix:** In 18.0, we do not support long search for the tracking_number, as it is not how we search for it. The way it works now is that depending on the length of the input, we search one way or another. If the input is 1 or 2 digits long, we search for those in the tracking number. If it's 3, we search for the last 2 digits in the tracking number, but the first input digit will be to search for the session_id. This is why we do not support inputs longer than 3 digits. To prevent this, we introduce a friendlier userError, as to inform the user that this is not possible, instead of a full traceback. This error was introduced when the function was changed in 36b5842 as a fallback was not implemented if the input was longer than 3 characters. The way we search for the tracking number is different in later versions, so the bug and the function itself are not there anymore. opw-5142216
This fix prevents users from changing tax report data by adding tax tags to journal items dated before the tax lock date. It helps keep locked tax periods stable and reduces the risk of accidental changes to already finalized tax reporting.
Original PR description
Despite the tax lock date, users are able to modify the tax report by adding tags.
**Steps to reproduce:**
Ensure the tax lock date is set
1. Journal Items list view
2. Edit one/many lines that
- have a date before the tax lock date,
- don't have a tax,
- nor tax tags,
- and is not a tax line.
3. Add a new tax tag
**Issue:**
The tax tags are added and might impact a tax report, when you should have received a user error.
**Cause:**
The `write` function calls the `_check_tax_lock_date` which in turn only checks the existing line instead of the values given in the `write` parameters. Since the line has no existing tax tags the check does not fail.
**Solution:**
Call the tax lock check both before and after writing the move line.
Task-5169152
Forward-Port-Of: odoo/odoo#232380This fix prevents unnecessary status updates from Ingenico payment terminals from disrupting point-of-sale payments. It helps avoid payment errors at checkout and reduces repeated database requests when the terminal status has not changed.
Original PR description
Currently when paying with ingenco there is an error: "Uncaught (in promise) TypeError: can't access property "payment_method", line is undefined." This is due to the fact that Ingenco sends requests to the database every second even when the status of the driver didn't change since the last payment. This PR fixes the issue by only sending requests to the database if a) THe driver status has changed b) A payment is being processed It also fixes the deprecation warning for isSet() replaced by is_set(). opw-5166439 opw-5181429 opw-5164612 opw-5170658 Forward-Port-Of: odoo/enterprise#97945
This change makes an internal website module test independent from demo data, reducing false failures in automated checks. It helps keep the release validation process more stable without changing customer-facing behavior.
Original PR description
runbot-162894 Forward-Port-Of: odoo/odoo#213962
Fixes an error that occurred when an HR responsible signed an offer for an employee who requested extra time off while automatic allocation was enabled. This helps HR complete salary package offers smoothly without manual workaround or interruption.
Original PR description
- When the employee requested extra time off, and the automatic allocation setting was turned on, signing the offer as the responsible HR caused an error. Task-5022631 Forward-Port-Of: odoo/enterprise#97955 Forward-Port-Of: odoo/enterprise#92663
This fix prevents Odoo from incorrectly showing a timezone mismatch warning when a user's computer and profile are both set to the same timezone with a 30- or 45-minute offset. It reduces confusion for users in regions with non-hour timezone offsets by only showing the warning when there is a real mismatch.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#230274
The Barcode app now rounds decimal quantities shown on the fulfillment button, avoiding confusing long decimal values during receipt processing. This makes scan counts easier for warehouse users to read and reduces display-only confusion without changing inventory quantities.
Original PR description
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54)…
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54) and mark it as To Do. - Open the Barcode app, open the corresponding receipt, and click the Edit button. - Increment the number of scans several times until you notice too many decimal digits (if you choose 10.54, you can test with 3). **Cause** A floating-point precision error occurs in the getter [`quantityToFulfill`](https://github.com/odoo/enterprise/blob/4b08734124c3bc84f7d95d170b39e9909e20d66b/stock_barcode/static/src/widgets/digipad.js#L55C9-L55C50), which is rendered directly [in XML templates](https://github.com/odoo/enterprise/blob/e8063141b33a9a8aa51d1ce94a66af313b2c1c89/stock_barcode/static/src/widgets/digipad.xml#L20C25-L21C89) without rounding. **Solution** Round the displayed value in the `quantityToFulfill` getter in the same manner than in [barcode_model](https://github.com/odoo/enterprise/blob/d4e5b69c7ea87fba3f2a5204ed6939b97879e4a8/stock_barcode/static/src/models/barcode_model.js#L99-L103). opw-5039796
This update corrects the Spanish Facturae electronic invoice signature template so generated invoices pass official validation. It removes an invalid placeholder from the signature digest field, helping avoid rejected electronic invoices for Spanish localization users.
Original PR description
Commit 051b7bcdd12d669e203296515e57ca8bfdac45e8 introduced an ___ignore___ in the DigestValue tag of signature_templates.xml which does not pass the facturae validation opw-5111038 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
Fixed an issue where German e-invoice files could show “Invoice Address” as part of the customer name when an invoice address had no contact name. The generated electronic invoice now uses the main commercial partner name instead, keeping XML invoice data consistent with the PDF invoice.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where validating a partial package transfer for products tracked and valued by lot could incorrectly fail with a missing lot or serial number error. Warehouse users can now split quantities into another package through barcode workflows without being blocked when the lot information is already present.
Original PR description
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to…
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to reproduce:** - Create product tracked by lot and valued by lot/SN. - Set on on hand quantity of 100 in stock with a package that you create and a lot that you create. - Create an internal transfer for 100 of this product. - Mark it as to do. - Open it in barcode. - Scan stock. - Scan the package. - Edit the line to quantity of 50. - Scan any other empty package already existing to set it as the delivery package. - Validate. - On the incomplete transfer widget, also click on validate. **Current behavior:** An error 'Lot/Serial number is mandatory for product valuated by lot' is triggered even though there is a lot on the line. **Cause of the issue:** When _assignEmptyPackage() is called to assign the new package, it calls shouldsplitline() which returns true because line.qty_done is smaller thant line.reserved_uom_qty https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/stock_barcode/static/src/models/barcode_picking_model.js#L949-52 Therefore, splitLine() is called and a new line is created with no package and no lot. Then, when we validate, _action_done() is called on the move which calls _action_done() on the move lines. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock/models/stock_move.py#L2065 In the stock_account override, the error is raised for the line newly created because it has no lot_id and no lot_name. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock_account/models/stock_move_line.py#L90-L91 opw-5028008
Users now receive a clear warning if they try to send batch invoices while the required scheduled process is disabled. This prevents silent failures and guides administrators to the right setting so invoices can be sent reliably.
Original PR description
This commit raises a RedirectWarning to the cron configuration to inform the user that the batch invoice cron must be enabled. Batch invoices cannot be sent if cron is disabled. task-5122707 Current behavior before PR: If batch invoice send is called and cron is disabled, then it will silently fail and not send. Desired behavior after PR is merged: If batch invoice send is called and cron is disabled, then it will raise a RedirectWarning to the cron configuration. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr