Daily updates from Odoo
Friday, August 29, 2025
24 changes · saas-18.3
Resolved issues and error corrections
Odoo now requires an update path when configuring server actions that update records. This prevents incomplete action setup and helps avoid errors when those automated actions run.
Original PR description
[FIX] base: make update_path required for 'Update Record' server actions If a server action was previously created without an `update path`, the resulting error already fixes with this commit [1]. This commit ensures that the `update_path` field is marked as required when the action type is set to `Update Record`. [1]: https://github.com/odoo/odoo/pull/217723/commits/9d0144f97795d71474bf84bdfd7ed7025fd8a9a2 Forward-Port-Of: odoo/odoo#224797 Forward-Port-Of: odoo/odoo#207928
Users can now enter an ampersand character in filter values without causing an error. This prevents crashes when creating or applying custom filters and keeps search workflows reliable.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281 Forward-Port-Of: odoo/odoo#224664 Forward-Port-Of: odoo/odoo#224567
Installing the Manufacturing app on very large databases is now less likely to run out of memory or time out. The update optimizes how existing stock movement data is prepared during installation, improving reliability for customers with high transaction volumes.
Original PR description
Description ----------- On large databases with millions of already existing `stock.move`, the post-install computation of compute stored fields can be time-consuming and memory intensive. This commit extends the pre_init_hook that was done in `mrp` to: - Speed up computation of `stock.move.is_done` - Implement SQL query to initialize `stock.move.manual_consumption`. Reference --------- opw-4980036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222299
This fix prevents remaining pop-up dialogs from getting stuck or causing crashes when another dialog is closed twice. It helps users complete actions such as employee holiday attestations without needing to refresh or encountering errors.
Original PR description
Have two dialogs opened, call twice `close` on one of them. From that point, the `stack` in dialog_service is empty (because the second time, the dialog can't be found in `stack`, so its index is -1,…
Have two dialogs opened, call twice `close` on one of them. From that point, the `stack` in dialog_service is empty (because the second time, the dialog can't be found in `stack`, so its index is -1, and calling `splice` with -1 removes from the end of the array), even though one of the 2 dialogs is still displayed. From that point, calling closeAll does not close the remaining dialog. In practice, this can be reproduced in Employees > Laurie Poiret (must be in BE company). In the cog menu, click on "Departure: Holiday Attest". In the dialog, click on the external button of the many2one. Close the second dialog by clicking on the X. At this point, `close` has been called twice for that dialog (once by the click on the cross, and once by an override of `dialogData.dismiss` in FormViewDialog), and `stack` is thus empty. Clicking on an action button in the first dialog (e.g. "Validate & Compute holiday attests") then no longer closes the remaining dialog as it should (as `closeAll` is called by the action service). Then, a crash can occur when manually trying to close that dialog, as the view in the background no longer exists, and closing the dialog calls its `onClose` callback, which tries to reload the view, thus leading to the "Component is destroyed" error. Issue introduced by https://github.com/odoo/odoo/pull/203169 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 fix updates an internal test in the Discuss area to use the proper test model. It helps keep automated checks reliable and prevents unrelated module dependencies from affecting test results.
Original PR description
PR #223438 uses `mail.test.rating` model (which belongs to `test_mail_full` module) as the test model in `test_discuss_full` module. This PR changes the test model to the correct one. runbot-231321 Forward-Port-Of: odoo/odoo#224630
This fixes an issue where refunds for lot-valued products sold through Point of Sale could leave the related inventory transfer unvalidated after closing the session. The correction helps ensure stock and valuation records are completed automatically, reducing manual follow-up for store and inventory teams.
Original PR description
When refunding a product that was lot valuated, the picking would not be validated automatically. Steps to reproduce: ------------------- * Create a product tracked by lot, and valuated by lot * Open…
When refunding a product that was lot valuated, the picking would not be validated automatically. Steps to reproduce: ------------------- * Create a product tracked by lot, and valuated by lot * Open PoS and create an order with this product * Validate the order and create a refund for it * Validate the refund * Close the session, and go to the picking of the session > Observation: The picking is not validated automatically. Why the fix: ------------ It was happening because the line that was put to 0 here (https://github.com/odoo/odoo/blob/eab97bed9c55a9057c7af7450ae1a09c6383a7b5/addons/point_of_sale/models/stock_picking.py#L249) has no lot assigned and should be deleted instead of just put to 0 quanity. It would then raise an error here (https://github.com/odoo/odoo/blob/2d933b83613ad52d76ab457201adecac6fcf184b/addons/stock_account/models/stock_move_line.py#L94) and cancel the validation of the picking. opw-4769042 Forward-Port-Of: odoo/odoo#224251 Forward-Port-Of: odoo/odoo#223888
This fixes an issue where POS loyalty points could be counted more than once if coupon confirmation was retried, such as after an internet interruption. The change helps keep customer coupon and loyalty balances accurate and avoids incorrect rewards being granted.
Original PR description
Before this commit, if the `confirm_coupon_programs` method was called twice (e.g., due to an internet issue), the loyalty points were calculated incorrectly. This commit fixes the issue by checking the existing loyalty history to prevent duplicate point calculations. To enable this, the creation of oyalty history records has been moved into the `confirm_coupon_programs` function. opw-4877599 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222372
Point of Sale now applies product pricelist rules in the correct quantity order instead of relying on internal record IDs. This prevents incorrect prices from being selected when multiple pricing rules exist for the same product.
Original PR description
Before this commit, the product pricelist items stored in IndexedDB were sorted by their `id`, which led to incorrect rule application in the PoS. When retrieving rules for a product, the order of rules matters. opw-4997926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222230
Point of Sale receipts now show tracking numbers only for restaurant or preparation-display workflows, avoiding unnecessary numbers in other checkout setups. Self-order and kiosk orders keep their S or K prefixes so staff can still identify order sources correctly.
Original PR description
- Fix issue where `tracking_number` was displayed for all config. We want to display this number only for `pos_restaurant` configurations. We also want to display it for POS config which have a preparation display configured (see enterprise linked PR). - Ensure Kiosk & Self orders correctly contains a prefix (S or K) inside their `tracking_number` to avoid regression. task-id: 4922308 enterprise PR: https://github.com/odoo/enterprise/pull/91833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222094
This fix ensures Turkish Nilvera e-Dispatch documents send the exact required true or false values instead of translated text. This helps avoid rejected or invalid submissions caused by language-specific translations changing required system values.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
Google Merchant Center shipping price generation now avoids excessive live carrier rate requests that could hit daily limits from providers like DHL. This helps keep product feed updates reliable while reducing the risk of blocked or throttled shipping quote requests.
Original PR description
### Issue: The `Google Merchant Center` calls the method `_prepare_gmc_shipping_info` in order to compute the best shipping price for each published product in each possible country: https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/website_sale/models/product_product.py#L352-L361 To achieve this, the method will request the shipping rate for each possible carrier, product, country. However, for external carriers, each such combination will require a request to the external api via the `rate_shipment`: https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/website_sale/models/delivery_carrier.py#L44-L53 This is problematic as external carriers have a standard rate limit (maximal amount of rate requests allowed per day). For instance DHL standard rate limit is 250 requests per day. opw-5048969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website SEO tools now avoid errors when Google suggestion data cannot be loaded or when a page has no description. This helps keep SEO previews and related website editing features stable for users.
Original PR description
Ensure the Google suggest fallback always returns a JSON list, even on IOError, instead of raising a serialization traceback. JS (SEOPreview): guard against undefined/empty descriptions with optional chaining and default empty string to avoid runtime errors. opw-4963552 Forward-Port-Of: odoo/odoo#224637 Forward-Port-Of: odoo/odoo#224424
Fixed an issue where validating an order in a non-restaurant Point of Sale session could also sync a separate draft order after a customer was selected. This helps avoid unintended draft order updates and keeps checkout data cleaner and more reliable.
Original PR description
Before this commit, in a non-restaurant PoS, when selecting a partner in a draft order, validating an order would also sync the draft order. opw-5037759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224041
Point of Sale now handles loyalty programs that are archived while already applied to an order. This prevents reload errors and helps keep checkout operations running smoothly when backend program settings change.
Original PR description
Before this commit, archiving a loyalty program while it was actively applied to an order could lead to errors. Specifically, if a PoS order had an active loyalty program applied, and that program was subsequently archived from the backend, reloading the PoS interface would cause issues or prevent proper functionality due to the program's sudden unavailability. opw-4941044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218814
This update fixes Turkish Nilvera e-invoicing issues so generated invoices better follow local compliance rules. It blocks invalid negative invoice lines, corrects discount reporting, removes an unnecessary product identifier from invoice XML, and resolves an access issue for users without the accounting add-on.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to fix certain compliance issues apparent in the UBL structure of Nilvera. an access right issue was also occurring when account is…
Description of the issue/feature this PR addresses: This PR aims to fix certain compliance issues apparent in the UBL structure of Nilvera. an access right issue was also occurring when account is installed but not account_accountant when doing check_nilvera_customer. Current behavior before PR: - access right error when doing check_nilvera_customer with account_accountant uninstalled. - negative lines were allowed in nilvera invoices and were reflected in the xml document. - StandardItemIdentification displays the products barcode under the invoice line. - multiplierfactor was not reflecting the discount % of the invoice line Desired behavior after PR is merged: - added read access to account module specific groups. - raise a blocking error if there are discount lines in the invoice. - remove the StandardItemIdentification node from the xml document - show discount % in the multiplierfactor task-4907751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224028 Forward-Port-Of: odoo/odoo#223136
Fixed an issue where changing the Peppol email address in the configuration wizard did not send the update to the connected service. This helps ensure companies' electronic invoicing contact details stay accurate without manual workarounds.
Original PR description
Due to the config wizard email address field being a related field, and the control flow triggering actual API update only on gets hit when the wizard's email is different from company's email, this control flow never triggered. The email field in peppol config wizard is a related field to companies peppol email, so the API update ran only if the wizard's email differed from the company's email. Since both were always the same by definition, the update never triggered. Depends on https://github.com/odoo/iap-apps/pull/1167 no-task Forward-Port-Of: odoo/odoo#224615
Barcode users will no longer see quality checks for products that have not been picked on a receipt. This prevents unnecessary or confusing checks and keeps barcode quality control aligned with the regular inventory workflow.
Original PR description
_______________________________________ ## Short functional explanation of the error On barcode, when an item isn't picked, when clicking on quality checks, the quality check for the unpicked item…
_______________________________________ ## Short functional explanation of the error On barcode, when an item isn't picked, when clicking on quality checks, the quality check for the unpicked item will still show. ## Reproduction Steps 1. Go to Quality and create a Quality point by clicking on Quality Control. Click on new, set a title and put 2 products in the field Product. In operation, select Receipt. 2. Go to Inventory and click Receipts. 3. Click New. Fill the Receive From field, and add 2 products. Set the demand field to 2 for example. 4. Click on Mark as Todo. 6. Go to Barcode. Click on Operations, the Receipts, and click on the latest Receipt you created. 7. For one product, click on the +2 button. For the other one, leave it at 0. Then, click on Quality Check. ### Expected behavior Only the quality check for the item that has been picked should show. ### Unexpected behavior Both quality checks show. ## Origin of the issue The behavior of the code is different when we perform the operations in backend compared to when we perform them in barcode. Thus, we have to change this behavior and take into account the environment. __ opw-5010764
Fixed an issue where stopping a timesheet timer could attach the recorded time to the previous or next day for users in certain time zones. The timer now uses the user's local date, helping ensure timesheet entries are placed on the day the work was actually performed.
Original PR description
Before this commit, if you were to log time on a timesheet using the timer start and stop buttons, you could potentially log time for the previous day's or the upcoming day's timesheet entry. This is because we were searching for previously-created timesheet entries based on the UTC Date of the timer's "stop" time. This fix uses the client's local time to get the Date of the timer stop. With this, we'll only find timesheet entries with the `date` field matching the client's local Date. opw-4967487 Forward-Port-Of: odoo/enterprise#93356 Forward-Port-Of: odoo/enterprise#92569
Receipts now show the correct tracking number when a point-of-sale setup uses a preparation display or preparation printer. This helps staff and customers match orders to receipts more reliably and reduces confusion during order preparation.
Original PR description
- Ensure the `tracking_number` is dipslayed on receipts for config which use a preparation dipslay or a preparation printer. task-id: 4922308 community PR: https://github.com/odoo/odoo/pull/222094 Forward-Port-Of: odoo/enterprise#91833
This fix prevents an unnecessary validation warning from appearing when a user changes a server action away from “update with AI.” It reduces confusion during configuration by only applying the AI-specific check when that action type is actually selected.
Original PR description
Bug === When setting a server action "update with AI", and switching to a different type of action, the validation error could be raised because we didn't check the `state`. Task-4989962
The VoIP CRM startup process now includes required user group information upfront. This avoids extra background checks when the web client opens, helping the VoIP app load more efficiently.
Original PR description
Since the VoIP app use some groups at startup[1], it's made sense to adds it inside the session_info bundle to avoid RPCs at webclient startup. [1]: https://github.com/odoo/enterprise/commit/9d3a13e9adae3a6b1c44b70a52b2fd74ef9dcc1a#diff-e8144e1aa7d3b4933985de5693d78e8c392bce8f7150ad186a04b8c87c7cd32aR14-R16
Published planning emails now send portal users to the correct planning page instead of the general portal dashboard. This prevents confusion for external users who need to view their assigned shifts from email notifications.
Original PR description
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on…
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on View Your planning - Notice you are redirected to the portal dashboard home ### Cause: Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26 ### Fix: We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view opw-5045746 Forward-Port-Of: odoo/enterprise#93359 Forward-Port-Of: odoo/enterprise#93333
Subscriptions with service products billed from delivered timesheets are no longer incorrectly treated as free renewals when the original order quantity or amount is zero. This ensures customers are invoiced for delivered work and helps prevent missed recurring revenue.
Original PR description
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product…
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product and set the qty to 0 - Create a Helpdesk ticket and link it to the SO - Record some timesheets in this SO - Run the cron for generating recurring invoices - Notice no invoice will be created for the SO and it will be considered as free renewal ### Cause: When trying to create a recurring invoice we check if the invoice that will get generated is free by checking the MRR and the total amount of the SO and if one of them are 0 we will flag this invoice as free so we won't generate it ### Fix: We check if the order lines to be invoiced is invoiced based on delivery and they have delivered quantity already and if so we create the invoice even if the MRR and the total amount is equal 0 opw-4990478 Forward-Port-Of: odoo/enterprise#93245 Forward-Port-Of: odoo/enterprise#93115
GSTR document summaries now ignore invoices that no longer have a valid invoice number. This prevents report generation errors and ensures only properly numbered invoices are included in compliance summaries.
Original PR description
_* = l10n_in_reports_gstr_document_summary Issue: - The GSTR document summary included all invoices that were posted or cancelled with posted_before = True. - If a user manually cleared the invoice sequence (set it to null), such invoices were still picked up. - This caused errors during summary generation since those invoices no longer had valid sequence numbers. Fix: - Adjusted the document summary logic to only include invoices with a valid sequence number. - Ensures that entries without a sequence are ignored, even if they were once posted. Impact: - Prevents errors when generating GSTR document summaries. - Guarantees that only valid, numbered invoices are included in reports. opw-5005048 Forward-Port-Of: odoo/enterprise#93039