Daily updates from Odoo
Sunday, April 26, 2026
5 changes
1 change
Resolved issues and error corrections
This update fixes a bug that occurred when a restaurant order with an active Fiskaly transaction was opened on multiple devices. Previously, the system failed to properly share transaction details, leading to duplicate transaction attempts and API errors. This change ensures consistent transaction state across devices, improving the reliability of the restaurant POS system.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#115170 Forward-Port-Of: odoo/enterprise#114599
1 change
Resolved issues and error corrections
This update optimizes the performance of the project list view, which is used to manage projects within the system. Previously, the view's rendering was slow due to inefficient calculations. Now, the system only checks for company differences once, significantly speeding up the loading time for project lists, especially those with many records.
Original PR description
Before this commit, to render the table, the project list view computed the list of selected records once for each cell, and then iterated over that selection to check whether selected projects were all associated with the same company (to set the stage_id field readonly if not). However, computing the selection requires to iterate over all records, so the rendering was O(n^2). As a consequence, the rendering of (not so) large tables was very slow (~1s for 80 records). With this commit, we compute only once for the whole table whether the selection contains records from different companies. Forward-Port-Of: odoo/odoo#260752
3 changes
Resolved issues and error corrections
This update enhances the account reports experience on mobile phones and tablets by ensuring the chatter is always visible and the annotation icon is consistently accessible via touch. Previously, the chatter was hidden on smaller screens, making it difficult to use. This change improves usability and allows users to easily interact with reports on any device.
Original PR description
Previously, the chatter was hidden on device too smalls and the annotation icon was only visible with hover so not visible on touch devices such as phones or tablets. Now, we have the chatter at the bottom when the device is too small and always display the annotation icon on touch devices. task-5106852 Forward-Port-Of: odoo/enterprise#114930 Forward-Port-Of: odoo/enterprise#95737
This update resolves a bug that occurred when a restaurant order with an active Fiskaly transaction was opened on multiple devices. Previously, the system didn't properly share transaction details, leading to duplicate transaction attempts and API errors. This fix ensures consistent transaction data across devices, improving the reliability of the restaurant POS system.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#115170 Forward-Port-Of: odoo/enterprise#114599
This update fixes an issue where deferred invoice moves weren't consistently linked to the correct customer partner. The change ensures that the `partner_id` is always taken from the original invoice line, improving data accuracy and preventing discrepancies in financial reporting. This enhances the reliability of deferred accounting processes.
Original PR description
When creating deferred move lines, the `partner_id` could be incorrectly influenced by the `default_partner_id` context key (e.g., when generating an invoice from a Sales Order). This led to inconsistencies where the deferred move lines did not match the partner on the original invoice line. This commit ensures the `partner_id` is explicitly taken from the source invoice line, guaranteeing data integrity across all deferred move lines. Steps: - Create a sale order for partner X, receive and confirm it - Create the invoice from the SO - Change partner to Y but keep X as delivery partner (not essential to reproduce bthough) - Set a deferred start date and a deferred end date on the invoice line, covering two full months - Confirm the invoice and open deferred moves via the smart button -> Note that one deferred move's lines get the partner id from the SO instead of the invoice opw-6095711 Forward-Port-Of: odoo/enterprise#115184 Forward-Port-Of: odoo/enterprise#114439