Daily updates from Odoo
Thursday, November 20, 2025
8 changes · 19.0
Enhancements to existing features
This change lets users specify the place where a service was delivered using the delivery address on a sales order or invoice. That address is now sent to the Brazilian tax and e-invoicing flow, so the issued service invoice can show the correct city where the service was provided.
Original PR description
Purpose: In Brazil, it is common for companies to sell services in one city and provide the services in another city, thus, it is necessary to inform the place of service provision in NFS-e. Users can specify where the service was provided through the delivery addresss on either sale order or invoice. The delivery address will be sent in the request to the tax calculation and edi. Outline of additional attributes being sent: - header.locations.rendered.address.street --> partner_shipping_id.street - header.locations.rendered.address.neighborhood --> partner_shipping_id.street2 - header.locations.rendered.address.zipcode --> partner_shipping_id.zip - header.locations.rendered.address.cityName --> partner_shipping_id.city - header.locations.rendered.address.state --> partner_shipping_id.state_id.code - header.locations.rendered.address.countryCode --> partner_shipping_id.country_id.l10n_br_edi_code task-5124608
The Philippine location database now includes all official provinces as states. This improves address accuracy and makes it possible to configure payroll and other processes at the province level.
Original PR description
Before: -The Philippine localization lacked province data in res.country.state. -Address and payroll setups couldn’t use province-level information. After: -Added all official Philippine provinces as states under the Philippines. Impact: -Improves address accuracy and enables province-based payroll configuration. task-5257793
The IoT service now loads IoT Box information in advance, which helps requests keep working even when connectivity is limited. It also reduces the number of database calls, improving responsiveness and lowering system load for related POS and self-order flows.
Original PR description
In order to allow iot requests to work offline, and also reduce the amount of orm requests sent to the db, we now preload IoT Box records in the `iot_http` service. Task: 5258886 Forward-Port-Of: odoo/enterprise#99910
This update clears existing UrbanPiper menu links and rebuilds them from scratch during synchronization. It helps keep the restaurant menu shown in UrbanPiper accurate and reduces the risk of outdated or duplicated menu connections.
Original PR description
Following this commit: - Flush out all existing UrbanPiper product menu linkages and performs a fresh menu sync. task-5231247 Forward-Port-Of: odoo/enterprise#98994
When half-day or hourly time off was moved to the next month, it could be treated as a full-day absence by mistake. This update keeps the deferred work entry aligned with the actual leave duration, improving payroll accuracy.
Original PR description
When deferring half-day or hourly leaves to the next month, the work entry was incorrectly replaced with a full day duration instead of the actual leave duration. Now splits the work entry to match the exact leave hours when necessary. task-5258753
The transcript download button is now available from the live chat info panel during an active conversation. This makes it easier for internal users to access and save chat records without waiting until the session ends.
Original PR description
Previously, the 'Download Transcript' button was only visible to visitors at the end of a live chat session. This limitation caused confusion since internal users could not download the conversation transcript from the interface. This PR adds the 'download transcript' button to the info panel, ensuring it is accessible from within the chat session as well. Task-5262296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock return wizard now shows one main action button, with the other options styled as secondary actions. The cancel action is also relabeled to "Discard," and users get clearer feedback when trying to return items with zero quantity, making the flow easier to understand and use.
Original PR description
Previously, the return wizard displayed multiple primary buttons, which could confuse users and affect the clarity of actions. This commit updates the wizard to have a single primary button, with all other action buttons changed to secondary for better user experience. Additionally, some button labels have been updated for clarity: - `Cancel` → `Discard` These changes make the return wizard more consistent, intuitive, and easier to use for all types of stock operations. This commit also enables improved user error when attempting to return products with zero quantities. Task - 5144914
This change makes large financial reports compute much faster by reusing already calculated account balances instead of recalculating the same data many times. It reduces waiting time for users running reports, especially on big databases, while keeping the result unchanged.
Original PR description
### Issue Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually…
### Issue
Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).
### Analysis
Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.
### Solution
Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.
For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.
### Benchmarks
Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types
| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |
### References
opw-5130725