Daily updates from Odoo
Sunday, April 26, 2026
9 changes
3 changes
Resolved issues and error corrections
This update fixes an error where employees were incorrectly paid 80% for rest days when on sick leave. The definition of a sick day requires employee absence due to illness, and rest days should be paid at full wage. This ensures accurate payroll calculations and compliance with regulations.
Original PR description
Currently, if a sick leave is spread over a weekend, the work entry type set on the saturday and sunday will be the sick leave type. If an employee is entitled sickness allowance (which is paid 80%), it means that we will be paying them 80% for their rest days as well. However, as per the definition, a sickness day is a day on which an employee is absent from work by reason of being unfit due to injury or sickness. If an employee is not expected to be at work (rest day), that day cannot be considered a sickness day. If this rest day is paid (which is done by default in our module), we should thus pay the full wage on that day and not a reduced 80%. task-6079736 Forward-Port-Of: odoo/enterprise#114995 Forward-Port-Of: odoo/enterprise#113486
This update resolves an issue that prevented users from successfully exporting General Ledger reports in certain configurations. The fix ensures that custom date ranges are properly formatted during export, preventing errors and improving the reliability of financial report generation. This ensures data integrity when exporting financial reports.
Original PR description
Since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 we have a custom_ranges option in the date filter. It needs to be sanitized like the other dates in order to avoid errors when JSON-serializing the options for export. Steps: - Install l10n_fr_reports and select FR Company - Activate the 'Fiscal Years' options and create one - Open the General Ledger report - Try to export the FEC file -> Traceback when validating the wizard opw-6107374 Forward-Port-Of: odoo/enterprise#113981
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
5 changes
Resolved issues and error corrections
This update resolves an issue where exporting financial reports (like the General Ledger) would fail due to a problem with custom date ranges. The fix ensures these date ranges are properly formatted for export, preventing errors and ensuring reports can be generated correctly. This improves the reliability of our reporting functionality.
Original PR description
Since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 we have a custom_ranges option in the date filter. It needs to be sanitized like the other dates in order to avoid errors when JSON-serializing the options for export. Steps: - Install l10n_fr_reports and select FR Company - Activate the 'Fiscal Years' options and create one - Open the General Ledger report - Try to export the FEC file -> Traceback when validating the wizard opw-6107374 Forward-Port-Of: odoo/enterprise#113981
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 a performance issue within the Timesheets assistant by automatically removing outdated suggestions from the local storage. Previously, these suggestions accumulated indefinitely, leading to slower performance. Now, suggestions older than 30 days are deleted, optimizing the system and improving user experience.
Original PR description
In the Timesheets assistant, we store the suggested events taken or dismissed by the user to avoid suggesting them again. However, there is no mechanism to remove them from the localstorage, so it currently grows infinitely. With this PR, we now delete events older than 30 days, to avoid filling the localstorage with useless data. Task-6131640 Forward-Port-Of: odoo/enterprise#114720 Forward-Port-Of: odoo/enterprise#114562
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