Tuesday, September 30, 2025
18 changes · 18.0
Enhancements to existing features
Link tracking redirects now encode certain repeated-dot characters in destination URLs. This helps prevent some web server configurations from incorrectly blocking valid tracked links as suspicious.
Original PR description
Purpose ======= It has been reported that some nginx configuration detect '...' as malicious. When testing, encoding the '...' solve the issue, and so we force the encoding for the redirection URL. Task-4920533 Forward-Port-Of: odoo/odoo#229060
Resolved issues and error corrections
Draft restaurant bills no longer show a misleading change amount before any payment has been made. This keeps early printed bills accurate for staff and customers and avoids confusion during service.
Original PR description
steps to reproduce: ------------------ 1. Install pos_restaurant 2. Go to Settings of the Restaurant and activate Early Receipt Printing 3. Go to dashboard > open restaurant > create an order 4.…
steps to reproduce:
------------------
1. Install pos_restaurant
2. Go to Settings of the Restaurant and activate Early Receipt Printing
3. Go to dashboard > open restaurant > create an order
4. Click on Actions > Bill > Print
issue:
------
The "CHANGE" line appears on the bill print even without a payment transaction.
cause of the issue:
--------------------
The condition:
https://github.com/odoo/odoo/blob/76757158c0ce4a29883c3c52c3378218ea755a8f/addons/point_of_sale/static/src/app/models/pos_order.js#L264 is responsible to display of "CHANGE" regardless of the order state, leading to incorrect printing while the order is still in DRAFT state.
solution:
---------
Add a check to ensure the order is not in DRAFT state before printing the bill.
**NOTE:** The issue no longer exists in later versions, as it was [resolved](https://github.com/odoo/odoo/commit/e11a3489a78334ad5d3395fd405b870fa1aa218b#diff-5f6173b111795dcdfe25b1fb26d55d27e1ce9c334eabe838d413fc35c5084d1aR1034-R1036) in commit e11a348.
<details>
<summary>Click here to see:</summary>
Before fix:
<img src="https://github.com/user-attachments/assets/4acd2322-ecae-4ff8-8421-234a9d00af86"/>
After fix:
<img src="https://github.com/user-attachments/assets/02edc28b-b1c1-40aa-b478-7a3419f2e736"/>
</details>
opw-5078803
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers in a newly created company without a configured warehouse will no longer hit an error when opening a product's inventory diagram. Instead, Odoo shows a clear warehouse setup warning so the user can correct the configuration and continue.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178
The Partner Ledger now keeps partner names and expand arrows neatly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
This fixes a problem where Discuss could crash if an update arrived for a call session that had already been removed. It improves reliability for users by safely ignoring outdated session updates instead of showing an error.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed.
The CRM periodic digest now states the correct number of free lead generation credits. This avoids misleading users by showing 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This fix updates the Indonesian e-Faktur buyer document values so invoices use the correct labels for Other ID and National ID. It helps ensure generated tax documents contain accurate buyer identification information, reducing confusion and compliance issues.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The cohort view export button is now disabled when there is no data to export. This prevents users from encountering an error when downloading reports from empty views, such as Helpdesk ticket analysis without records.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426
This fix ensures the main DATEV account is only applied to companies based in Germany, preventing incorrect accounting setup for companies in other countries. It also improves how debit and credit lines are gathered, making the process more efficient for larger accounting entries.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fix restores hover tooltips for text fields added to sale order lines, including fields added through Studio. Users can now see the expected cell details when hovering, improving readability and reducing confusion when editing orders.
Original PR description
## Versions 18.0+ ## Issue No tooltip can be displayed on Sale Order Lines. ## Steps to reproduce *Install Studio* - Open any SO; - Open Studio: - Click "Edit List view" on the Order Lines table; - Add a "Text" field in the columns; - Close Studio. - Add a product line if none: - Write something in the new column added with Studio; - Hover that cell and see no tooltip appear ## Cause https://github.com/odoo/odoo/blob/4daf4824a70ef679f65d5cbb15d71bc55c1e760e/addons/web/static/src/views/list/list_renderer.xml#L250 The template calls `getCellTitle` which returns a formatted text but has been overridden. These methods call the original `getCellTitle` method but don't return the formatted value. opw-4921113
This fixes an automated purchase inventory test so it behaves consistently when Kenya localization settings are installed. The change helps prevent false test failures and supports more reliable release validation without changing business workflows.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221042
Helpdesk ticket lists now sort ticket references in the expected numerical order, even after ticket numbers reach 100. This makes it easier for users to find the oldest or newest tickets without confusing ordering caused by text-based sorting.
Original PR description
**Issue** With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets. opw-4891916 Forward-Port-Of: odoo/enterprise#93058
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229085
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229085
Swedish payment files now correctly label bankgiro accounts with the required BGNR account type instead of BBAN. This helps bank transfer files be accepted and processed correctly for companies using Swedish bankgiro payments.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368
This change fixes an unstable automated test for the HTML editor by ensuring the editor toolbar is fully ready before the test continues. It helps prevent false test failures, improving confidence in releases without changing user-facing behavior.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090
This change adds checks to ensure keyboard formatting shortcuts work correctly when no text is selected in the HTML editor. It helps prevent unwanted undo history entries and keeps editing behavior consistent for users.
Original PR description
Description of the issue this PR addresses: This PR adds test cases for formatting shortcuts (e.g., Ctrl+B) on a collapsed selection. An empty inline tag is inserted temporarily and auto-cleaned if unused, so no individual history step are created. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product prices on the website now display using the currency's configured rounding, so currencies set to show no decimals will no longer appear with two decimals in normal customer sessions. This keeps storefront pricing consistent between editor preview and customer-facing pages.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878 Forward-Port-Of: odoo/odoo#224429
Prices in the rental eCommerce flow now respect the website currency's decimal precision for public visitors. This prevents prices from incorrectly showing two decimal places when the business has configured a different currency format, such as no decimals.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#95634