Daily updates from Odoo
Tuesday, August 19, 2025
13 changes · 18.0
Resolved issues and error corrections
This fix ensures Odoo consistently waits for file uploads to finish before users can send messages or manage attachments. It prevents confusing behavior such as attachments being deleted too quickly or messages failing when sent with the Enter key while an upload is still in progress.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620
This fix restores the review summary information shown in portal rating areas, so customers and visitors can see rating feedback as expected. It also updates related portal and website modules plus tests to prevent the issue from returning.
Original PR description
*: portal_rating, rating, test_mail_full task-4853416
Inter-company customer invoices now correctly display lot and serial numbers for delivered products. This helps businesses keep accurate traceability records when selling between companies in the same Odoo environment.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Combo products now keep the correct pricelist discount from product page through checkout. This prevents customers from seeing misleading original prices or a crossed-out zero price, improving pricing clarity in online purchases.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848
Fixes an issue where completed manufacturing orders could not be unbuilt if their components were later changed to require lot or serial tracking. This lets businesses reverse eligible production orders without unnecessary blocking errors while preserving normal tracking rules for components that were tracked originally.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally…
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally require tracking (no lot/serial), but have been updated later to require it. When unbuilding such a product, `stock.move.line._action_done` currently raises a UserError requiring a lot/serial number, because the component moves created by `mrp.unbuild`: - do not have a picking_type_id, - are not inventory moves, - are not scrap moves, - and lack lot/serial information. However, in this context, the lot requirement is misleading, as the original `mrp.production` did not generate tracked components. It is valid to restore untracked components even if they are now tracked. **Current behavior before PR:** - Create an `mrp.production` for a product with untracked components. - Complete the production. - Later, enable lot tracking on one or more of the original components. - Attempt to unbuild the production. - ❌ Error is raised: “You need to supply a Lot/Serial Number for product…” **Desired behavior after PR is merged:** - The unbuild operation proceeds without error. - The untracked components are restored correctly. - Behavior remains unchanged for tracked components that did require lot info during the original MO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217282
The website events list now uses the visitor’s local day when applying the “Today” filter, instead of relying on UTC. This ensures events are shown on the correct date for users in different time zones, avoiding missed or incorrectly listed events.
Original PR description
The filters use today in UTC to fetch events in db. The commit fixes this by located today first and then converts it in UTC. related odoo/odoo@bfd55de7c846a0d523e4de4b17020341d8fcfd23 task-4796181
This fix prevents vendor bills or invoices marked as blocked from being automatically unblocked during reconciliation or related accounting updates. It helps preserve payment controls and avoids accidentally allowing payments that were intentionally put on hold.
Original PR description
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if…
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if an invoice has been marked as blocked, it might be automatically unblocked during reconciliation. Solution: The `_compute_payment_state` method will now prioritize a move's `payment_state` being blocked over whether it has been posted. This prevents a blocked move from being unblocked unexpectedly. Steps to Replicate (Runbot 18) - Create a product - Track inventory - Cost > 0 - Control policy = On ordered quantities - Product category is valuated in real-time (Inventory Valuation - Automated) (requires 'Stock Accounting Automatic' group) 1. Create a PO for the product 2. Create a bill, validate it 3. Block the bill using the contextual action 4. Receive the product If you navigate back to the Vendor Bill, you will see that it has been unblocked. opw-4981799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi Arabia point-of-sale receipts now encode the local KSA time in their QR codes instead of UTC. This ensures scanned e-invoice details match the printed receipt and follow ZATCA expectations.
Original PR description
**Problem:** If you have an SA company, and try to scan the QR code generated on the receipt, the time will be the UTC time instead of the KSA time, as we are in SA. **Steps to reproduce:** - Change your company to SA and install l10n_sa_pos - Make a purchase with a customer from SA - Scan the QR code from the receipt using an app such as E-invoice QR reader - The invoice date will be the UTC time, or 3 hours less than it should **Why the fix:** Before this fix, the time was always displayed as UTC. It could have been correct if it also displayed a 'Z' in the end, to indicate that it is not local KSA time. We now directly change it using the KSA time, to respect the ZATCA guidelines. The time is now the same on the printed invoice and in the app when scanning the QR code. opw-4769521
Slovenian domestic customers without a VAT number are now assigned the correct domestic fiscal position instead of being treated as EU customers. This prevents domestic sales revenue from being posted to the wrong accounts, improving accounting accuracy for Slovenian businesses.
Original PR description
Before this PR: - Domestic customers without VAT were incorrectly mapped to EU fiscal position, causing domestic revenue accounts (760000) to be mapped to EU accounts (761000). After this PR: - Added new domestic fiscal position for non-VAT customers to ensure proper account mapping for domestic transactions. Task-4918960 Forward-Port-Of: odoo/odoo#217311
A scheduled billing process could stop too early when the first batch included subscriptions that were not ready to invoice, potentially delaying invoices for other eligible subscriptions. This fix applies the batch limit after checking which subscriptions can actually be invoiced, helping ensure renewal invoices are generated on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884
Fixes an issue where running a WhatsApp marketing automation test more than once could cause an error and stop the test. The automation now handles each tracking record separately, improving reliability for users validating WhatsApp campaigns.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612**
The Point of Sale system now checks connected device status less frequently, moving from every 5 seconds to every 60 seconds. This reduces unnecessary background work and can help stores with large product databases avoid slowdowns during PoS use.
Original PR description
We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short. For databases with a lot of products this can unnecesarily slow down their PoS This PR increases the loop until 60s opw-5006302
Non-recurring products sold through upsell orders are now included in the Sales Analysis Report. This gives teams a more complete view of delivered quantities and revenue, improving sales reporting accuracy.
Original PR description
Problem: The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate…
Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.
Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.
Steps to reproduce the bug:
1. Create a Sales Order (SO):
Add two products to the order:
- One recurring product (e.g., a subscription-based product with a recurring billing policy).
- One non-recurring (standard) product.
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully).
5. Create an Upsell Sales Order:
- From the original SO, create a new upsell SO.
- Add the same non-recurring product again.
6. Navigate to the Non-Recurring Product Page:
- Open the Product form for the non-recurring item.
- Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
- This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.
Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.
opw-4940977