Tuesday, September 9, 2025
10 changes · 17.0
New functionality added to Odoo
This update adds a shared way for Odoo modules to provide business KPI summaries. Accounting now contributes draft document counts by type, making it easier for future dashboards or setup flows to display consistent performance indicators.
Original PR description
This commit introduces a new abstract model `kpi.provider` that allows different modules to contribute their Key Performance Indicators (KPIs) in a modular and extensible way. The `kpi.provider` model defines a base structure for KPI reporting and includes a `get_kpis_summary` method that should be overridden in inheriting models. This method is responsible for returning a list of KPI data specific to the module. KPI data are identified by a unique name and a type allowing for the caller to know how to present the corresponding value. The `account` module inherits from `kpi.provider` to include the amount of draft `account.move` for each `move_type`. Task-id: 5062431 Forward-Port-Of: odoo/odoo#225153
The Documents app now includes the number of items in the Inbox folder in its KPI summary. This gives users a quick business overview of pending documents that may need attention, without opening the folder separately.
Original PR description
With this commit, `kpi.provider.get_kpi_summary` will show how many documents are present in the Inbox folder. Task-id: 5062431 Forward-Port-Of: odoo/enterprise#93720
Resolved issues and error corrections
The Uruguay localization now links directly to its dedicated documentation page instead of a general fiscal localization page. This helps users find the right country-specific guidance more quickly from the app information.
Original PR description
Description of the issue/feature this PR addresses: The website link in the `l10n_uy` manifest was pointing to a generic documentation page. Current behavior before PR: Link in manifest points to `https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations.html` Desired behavior after PR is merged: Link in manifest points to `https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/uruguay.html`
A mail thread that previously failed to load messages will now clear the error state after a successful retry. This prevents users from seeing stale failure messages once their messages have actually loaded, such as after reconnecting to the internet.
Original PR description
Backport of : #222001 **Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However,…
Backport of : #222001 **Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch attempt succeeds, the flag is not reset. As a result, the UI may continue to show an error state even though the data has successfully loaded. **Steps to Reproduce:** - Open a thread with many messages. - Go offline. - Scroll up to load older messages → failure message appears. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> - Go back online and click Retry → messages load successfully. - Scroll again → failure message still appears, even though you’re online. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> **Current behavior before PR:** After a failed attempt to fetch messages in a thread, the `hasLoadingFailed` flag remains set to `true`. Even if the user goes back online and the subsequent fetch succeeds, the UI continues to show a failure state. **Desired behavior after PR is merged:** After a successful fetch of a thread’s messages, the `hasLoadingFailed` flag is reset to `false`, ensuring the UI no longer shows a failure state once the data has been correctly loaded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing users can now update the scheduled date on manufacturing orders without being blocked by permissions on related stock movements. This removes an access-related error in a common planning workflow while keeping the change limited to the manufacturing module.
Original PR description
#### Issue and steps to reproduce: 1- Login as demo user 2- Create a MO and save it 3- Update the schedule date and save As you see there the stock move unlink access prevents user to update the MO This PR is a backport of #153671 opw-5038258
The website shop price range filter now works correctly when shoppers use a close but misspelled search term. This keeps filtering aligned with the products actually shown, reducing confusion during product discovery.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545The invoice PDF for Mexican electronic invoicing now shows the same customer fiscal regime as the official CFDI XML. This prevents mismatches when invoicing a child contact whose fiscal regime differs from the parent company, reducing confusion and compliance risk.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605
Swiss payroll ELM transmission payslips now base their displayed name on the employee's first and last name. This prevents incorrect or unclear payslip naming, making payroll records easier to identify and process.
The bank reconciliation report no longer counts exchange rate adjustment entries as bank activity. This prevents currency revaluation differences from appearing under miscellaneous operations, giving finance teams a clearer and more accurate reconciliation view.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870)
This update fixes an internal rental stock test so it works correctly in environments without demo data. It ensures the required accounting and stock setup is handled during testing, reducing false failures and improving release reliability.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417