Daily updates from Odoo
Tuesday, October 21, 2025
31 changes · saas-18.3
Resolved issues and error corrections
Customers who navigate back during checkout and choose another delivery address are now handled safely instead of seeing an error page. If the cart is no longer available, the shopper is redirected back to the shop, reducing checkout disruption and support incidents.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801 Forward-Port-Of: odoo/odoo#226781
Spanish Facturae invoice XML now uses the correct total tax amount when global tax rounding is enabled. This prevents mismatches between invoice totals and the electronic invoice file, reducing the risk of rejected or inaccurate e-invoices.
Original PR description
When `l10n_es_edi_facturae` is installed, creating an invoice with 25 identical lines (price_unit: 230.83, quantity: 1, tax: 21%) and global tax rounding enabled results in: - Untaxed amount: 5770.75 - Tax amount (globally rounded): 1211.86 However, the generated Facturae XML incorrectly reports `TotalTaxOutputs` as 1211.75, as if tax was rounded per line. This was caused by the `_l10n_es_edi_facturae_export_facturae` method which round lines individually before the summing them even if the rounding method is global. opw-5111038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adjusts Swiss payroll employee views so payroll data can be handled correctly in environments with more than one company or country. It helps businesses using Odoo payroll in Switzerland avoid configuration or visibility issues when operating across multiple entities.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#97489 Forward-Port-Of: odoo/enterprise#96733
This fixes an issue where saved payment methods were not offered when registering payment for an invoice tied to an individual contact within a company. The payment form now uses the invoice's actual customer, helping users reuse stored payment details correctly.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Payroll now checks the correct document template separately for each payslip, even when no template is available in some cases. This helps prevent incorrect or missing payroll document generation when processing multiple payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template.
This fix improves the spacing between labels and fields in event website menu settings shown in debug mode. It makes it easier for administrators to understand which option belongs to which label when configuring event page menus.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
This change removes a browser-specific setting from local IoT device requests in Point of Sale because it caused errors in older Chrome versions and was not needed for Odoo's secure connections. It helps keep POS hardware and customer display interactions working consistently without changing business workflows.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232289 Forward-Port-Of: odoo/odoo#232110
This update removes an unnecessary browser request setting used when connecting Odoo Point of Sale to local IoT hardware. It helps avoid connection errors in older Chrome versions while keeping existing secure local device communication working as expected.
Original PR description
This reverts commit 6d09dc6 which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 Forward-Port-Of: odoo/enterprise#97624 Forward-Port-Of: odoo/enterprise#97500
The Documents app now correctly responds when users turn debug mode on or off from the command palette. This keeps navigation links accurate and avoids confusion when switching modes without manually editing the URL.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
The returns wizard now generates all applicable returns from the opening date chosen by the user, instead of limiting results to the current fiscal year. This helps businesses produce complete return periods when starting or reopening accounting from a specific date.
Original PR description
If the user generates the returns with the wizard of the opening date, he expects to generate all the returns from this date, and not just for the current fiscal year like it used to be. backport of a request of task 5030701
The Accounting journal dashboard cards now have a slightly taller minimum height. This makes cards without graphs better align with those that include graphs, creating a cleaner and less confusing dashboard layout.
Original PR description
The min height for the kanban journal dashboard in Accounting makes it looks currently like this is an unwanted behavior. This PR slightly increase it to match the cards having graphs on it. task-4792156 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
A new action is available on the accounting returns screen so users can create returns directly when needed. This makes the process easier and avoids relying only on automated or indirect creation flows.
Original PR description
Add a new button on the returns view to create new returns. task-4627315
Italian point-of-sale setups using a fiscal printer and cash drawer now print receipts correctly when completing a sale. This prevents checkout interruptions for businesses that need the cash drawer option enabled.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
This change prevents spreadsheet print styling from interfering with other areas of Odoo by removing it from a shared backend asset bundle. It helps avoid blank pages when printing or exporting content while keeping spreadsheet printing available through its dedicated print setup.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing Print Assets (Public View)** The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode. ### Fix This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle. The remaining issues are tackled in odoo/enterprise#92665 opw-4816241 Forward-Port-Of: odoo/odoo#230552 Forward-Port-Of: odoo/odoo#223434
Public and portal users can now print or export shared Knowledge articles without getting blank pages. The update fixes missing print styling and removes a Planning style conflict, improving reliability for shared article access.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96625 Forward-Port-Of: odoo/enterprise#92665
Fixed an issue where required matrix questions in surveys could fail if their description included a table. This prevents errors for respondents and ensures surveys with richer formatting continue to work correctly.
Original PR description
A conflict occurs if a matrix question is set to "Mandatory answer" (questionRequired = True) and a table is also added to its description. The issue is that when the system evaluates a required matrix, it gets the subQuestionsIds by looking for the first table within the question's wrapper. If a table exists in the description, the system incorrectly tries to retrieve the IDs from that table. This action throws a traceback because the descriptive table does not contain any sub-question data. This commit fixes the issue by being more specific when looking for the table containing the subQuestionsIds. It adds a specific class to this table and uses it in the selector. An attribute selector, like 'table[data-sub-questions]', could also have been used as an alternative. opw-4931881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229909
Accounting users can now create SEPA Direct Debit mandates without encountering an access error. This ensures authorized invoicing and banking staff can complete mandate setup without requiring administrator permissions.
Original PR description
Have the Payment Provider Sepa Direct Debit module installed. Connect with a user with access right for Accounting: Invoicing & Banks. Create a Direct Debit Mandate => Get an access error. Reason: the compute does a read_group with a value on payment.provider, which non System Admin have no access to. Solution: Add a sudo for these _read_group
This fixes duplicate screenshots and videos being created when automated tests fail. It makes failure evidence more reliable and avoids extra processing or crashes in the test system, helping development teams diagnose issues faster.
Original PR description
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok`…
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure. Do a bit of rejiggering to fix things up: - in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing) - only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already. And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs.
This fix removes an outdated requirement that the online store be publicly accessible for Google Merchant Center product feeds. Feeds now rely on access tokens, so businesses can keep the intended access setup while still allowing authorized Google feed retrieval.
Original PR description
Initially, a constraint was added to ensure the eCommerce site was publicly accessible, allowing Google to access the feed without requiring authentication. However, the updated version of GMC no longer relies on this constraint. Instead, it uses an access token to authorize feed access. A previous attempt ([^1]) to remove this constraint targeted the wrong model. This commit corrects that mistake. [^1]: https://github.com/odoo/odoo/pull/225536
OdooBot's preconfigured canned responses are now shared with the appropriate user group, making them visible to users as intended. This fixes an issue where default and demo canned responses existed but could not be seen or used by anyone.
Original PR description
**Description of the issue this PR addresses:** Modify Canned Response master and demo data **Current behavior before PR:** Before this PR, canned responses created by OdooBot in master and demo data were not shared effectively, so they were not visible to anyone. **Desired behavior after PR is merged:** This PR ensures canned responses created by OdooBot are shared properly, by assigning a user group, ensuring that everyone can see them. task-[5069111](https://www.odoo.com/odoo/project/1519/tasks/5069111) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231976 Forward-Port-Of: odoo/odoo#228006
Shipping notification emails for Gelato orders now use the correct tracking link when an order has a single parcel. This prevents customers from being sent to a broken tracking page and improves the post-purchase delivery experience.
Original PR description
After receiving the shipping webhook from Gelato, we send a shipping notification with the tracking information to the customer. This commit fix the tracking url for single parcel, which was pointing to an inexistant url. opw-4637331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232395 Forward-Port-Of: odoo/odoo#232071
VoIP contact search now combines phone keypad search terms correctly with other contact filters. This should make matching contacts appear more reliably when users search from VoIP.
Original PR description
t9_search should be ORed to the subdomain, which in turn should be ANDed to the domain. Currently, both the subdomain and the t9_search are ANDed to the domain, resulting in a "subdomain AND t9_search" condition, which is not correct and unlikely to match anything.
This fix prevents an error when settling invoices in Point of Sale if a customer's related company record was not fully loaded. Staff can now complete invoice settlement more reliably without being blocked by missing background customer data.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-5112883
The product barcode lookup process now avoids duplicate scheduled image-fetch jobs by replacing any existing job before creating a new one. This keeps background scheduling efficient and reduces the risk of unnecessary processing or timing errors.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected. Forward-Port-Of: odoo/enterprise#97411
This fixes an issue where reconciling journal items could fail in setups with customized default journal entry types. The reconciliation wizard now consistently creates write-offs as standard journal entries, reducing interruptions for accounting users.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
UPS shipment requests now include the company's and customer's VAT details, so commercial invoices generated for international deliveries show the correct tax information. This helps businesses avoid incomplete shipping documents and reduces manual follow-up for cross-border shipments.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356
Odoo now checks only actual email messages when deciding whether to block a sender for sending too many repeated messages. This prevents normal users from being incorrectly blocked because other internal message types were counted as emails.
Original PR description
When detecting loops with _detect_loop_sender if the count of these messages exceeds the LOOP_THRESHOLD, the next email from that user is blocked, even if the number of new emails alone hasn't yet crossed the threshold due to mail messages that are not email triggering the loop detection. This happens because it searches for messages in the mail.message model that share the same model name and author irrespective of the message type. To correct this, the function's search criteria must be modified to explicitly filter for messages where the message_type is set to 'email'. opw-5122962 Forward-Port-Of: odoo/odoo#232026
Updated an automated payroll test so it remains reliable with recent Chrome changes in how text styling is reported. This helps prevent false test failures and keeps payroll development checks stable without changing user-facing payroll behavior.
Original PR description
Since either 140 or 141[^0] Chrome uses compact serialization rules for text-decoration, as a result of w3c/csswg-drafts#12486. This was merged [on August 12th][CL-6824265] and Chrome 139 was cut on August 5 so couldn't have had this change. The new serialization rule means values which can be ommitted from a shorthand (default or fallback) should be, so the default `text-decoration-line` and a `text-decoration-color` matching the `color` won't be serialized in `text-decoration` anymore. Instead of matching the shorthand, match the actual stored properties. [^0]: 140 was not deployed on chrome next so it may or may not have been broken then [CL-6824265]: https://chromium-review.googlesource.com/c/chromium/src/+/6824265 Note: this commit is a backport of odoo/enterprise@eddbdb2d9593b331c5ef641b7747ec61c736d84d Forward-Port-Of: odoo/enterprise#97719
This update adjusts an internal web interface test so it remains reliable after a small behavior change in Chrome 140. There is no expected functional impact for users; it helps keep Odoo's automated quality checks stable across browser versions.
Original PR description
In Chrome 140, a fix [^0] has been applied regarding the `offsetParent` property with a fixed position element. Due to this fix, a resizable panel's test failed by 1px. As this difference doesn't have a real functional impact, we adapted the test to accept both the pre/post fix values. Note: that it is also related to a clarification [^1] in the CSS spec [^2]. [^0]: https://chromium-review.googlesource.com/c/chromium/src/+/6774502 [^1]: https://github.com/w3c/csswg-drafts/issues/12352 [^2]: https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsetparent Forward-Port-Of: odoo/odoo#232458
Code cleanup and technical improvements
This update applies standard code quality tooling across the VoIP area without changing customer-facing functionality. It helps keep the calling features easier to maintain and reduces the risk of future issues from inconsistent code style.
Documentation and clarification updates
The contributor list has been updated to include Acsone and Tobias Zehntner after confirming the required contributor agreement. This keeps Odoo's contribution records current for legal and compliance purposes.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232278