Daily updates from Odoo
Friday, May 22, 2026
11 changes · master
Resolved issues and error corrections
This update fixes an error that prevented users from viewing historical payslip data. The issue stemmed from a recent change that removed a key component, causing a system error. The fix ensures that users can now access and review their payslip history without encountering this problem.
Original PR description
Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values. Steps to Reproduce: - Install the `l10n_id_hr_payroll` module with demo data. -…
Currently, an error occurs when users click on View GROSS/PPH21/JHT/JP History to see historical payslip line values. Steps to Reproduce: - Install the `l10n_id_hr_payroll` module with demo data. - Switch to the `Indonesian` company. - Go to `Employees` and open an `existing record or create a new one`. - Click on `GROSS/PPH21/JHT/JP History` button. `ValueError: External ID not found in the system: hr_payroll.act_contribution_reg_payslip_lines` The issue occurs because, in [this commit], the act_contribution_reg_payslip_lines window action was removed. However, when viewing historical lines, and it still tries to retrieve this action using its XML ID [1] and then updates its domain, context, and views. As a result, it raises an error due to the missing XML ID. This commit ensures that the method returns a standalone window action dictionary instead of relying on the removed window action record. [this commit]: http://github.com/odoo/enterprise/pull/112571/changes/7094cdc033591258cae7c7df46888c29eaae6248 [1]- https://github.com/odoo/enterprise/blob/103500a805d1ffc1185ed639d613c2d1ede492cb/l10n_id_hr_payroll/models/hr_employee.py#L17-L24 sentry-7489148694 Forward-Port-Of: odoo/enterprise#117683
This update resolves an issue preventing users from adding multiple images to product pages within the AI website sale module. The fix corrects a technical error related to how image loading was handled, ensuring the feature now works as intended. This improves the presentation of products with multiple images.
Original PR description
Steps to reproduce: =================== 1. Install ai_website_sale 2. Go to a product page and enter edit mode 3. In the right panel => Images => click "Add More" (Extra Media) 4. Select a PNG or JPG image and click Add => TypeError: loadPromiseResolveFunction is not a function Cause: ====== The `ai_website_sale` patch for `ProductAddExtraImageAction.getMediaDialogProps` destructures the argument with key `loadResolveFunction` (renamed to `loadPromiseResolveFunction` locally), but the caller in `load()` passes `loadPromiseResolveFunction` as the key. The key mismatch means the local variable is always `undefined`, and the `save` closure in the parent's `getMediaDialogProps` closes over `undefined` instead of the Promise's `resolve` function. Fix: ==== align the parameter key. It's a backport of this commit https://github.com/odoo/enterprise/commit/e5b89df328601af881af115c6083a648af0cc1a1 opw-6215476 Forward-Port-Of: odoo/enterprise#117454
This update resolves an issue where removing a general note from a restaurant orderline caused the preparation display to incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#118119 Forward-Port-Of: odoo/enterprise#113514
This update eliminates a redundant type definition file that was causing issues with the OWL package. Removing this file resolves a technical problem, ensuring the enterprise version of Odoo functions correctly. This change improves stability and performance.
Original PR description
This commit removes the `@types/main.d.ts` file, as it seems it is not necessary and was preventing the types from the installed OWL package from being used. Before: <img width="689" height="74" alt="image" src="https://github.com/user-attachments/assets/f25ca51d-0ef7-466d-9b89-0c80047b0f97" /> After: <img width="571" height="52" alt="image" src="https://github.com/user-attachments/assets/c54455ed-279f-4449-aa77-08dd822203d2" />
This update ensures that reconciliation models created directly by users in Odoo always take precedence over those automatically generated by the system. Previously, there could be conflicts in prioritization, leading to potential issues with reconciliation processes. This change improves reliability and user control over reconciliation workflows.
Original PR description
The reconciliation models created by users now always have priority over the models that are automatically created by odoobot no matter what the sequence is. task-6086528
This update fixes an error in the WPS payroll report generation process. Specifically, it ensures the report accurately reflects payment dates and values, preventing potential discrepancies. The changes include correcting a tooltip and adding a validation check to ensure payment dates are before the value date.
Original PR description
In this commit, we: - corrected the tooltip description of `l10n_sa_wps_value_date`; - added back the Debit Date to the WPS file and assigned it the value of the `effective_date`; - added back the user error in case the Payment Date is greater than or equal to the Value Date. TaskID-6130969 Forward-Port-Of: odoo/enterprise#115762
This update resolves an error that occurred when automatically checking out employees with no defined check-out date, specifically when the hr_attendance and hr_work_entry_attendance modules are used. The issue stemmed from incorrect timezone handling, leading to the creation of duplicate overtime entries. This fix ensures accurate automatic check-out calculations.
Original PR description
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both…
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both installed. When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs. ## Reproduction Steps 1. Install hr_work_entry_attendance. 2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset. 3. In Settings, check the Automatic Check-out box. 4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty. 5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually. ### Expected behavior The attendance check-out should be set at the end of April 17th. ### Unexpected behavior An error occurs: `Expected singleton: hr.attendance.overtime.line(39, 40)` ## Origin of the issue When the attendance goes over several days, we set the check-out date to: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error. https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59. Because of that, at the return: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April. We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance. So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs. __ opw-6036064 Forward-Port-Of: odoo/enterprise#115828
A test related to embedded account reports was failing due to inconsistencies in demo data. The fix ensures the test accurately validates report options by generating the necessary account reports within the test itself, regardless of whether demo data is loaded. This resolves a runbot error and maintains test reliability.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235 Forward-Port-Of: odoo/enterprise#117231 Forward-Port-Of: odoo/enterprise#112486
This update corrects a visual issue where the project sharing notebook was using dark styles, causing a conflict with the light mode theme. The team removed a specific style file to ensure consistent appearance across Odoo Enterprise.
Original PR description
The project sharing notebook previously used dark-themed styles, which conflicted with the light mode .Removing the notebook.dark.scss file from the imported files in the manifest. task-4922564 Forward-Port-Of: odoo/enterprise#99161
This update adjusts the formatting of numeric values in account reports to align with the overall column styling. The change adds a small padding to the header, creating a more consistent and visually appealing report. This improves the readability and presentation of financial data.
Original PR description
the following commit slightly modified the styling of reports header by alligning the text on the right for numeric values to match the styling of the values in the column. However, the forward port in 19.3 didn't notice that a small padding was now present in the version. https://github.com/odoo/enterprise/commit/196aa04b301499fdb2ea0769f7f07ff504a46b2b In addition, no class is needed for budget columns since no names are provided. **BEFORE** <img width="776" height="252" alt="image" src="https://github.com/user-attachments/assets/02c9dbb2-ab68-4b81-abb4-08db7f663794" /> **AFTER** <img width="518" height="276" alt="image" src="https://github.com/user-attachments/assets/3fb86584-6699-4b49-b2b9-87685bad0c16" /> Forward-Port-Of: odoo/enterprise#117920
This update simplifies how text is clipped in website content, primarily within the website_appointment and related modules. The change replaces older, browser-specific code with a more flexible and maintainable approach using a standard CSS class and variable. This ensures consistent text clipping across different browsers and allows for easier customization of the number of lines displayed.
Original PR description
*: website_helpdesk, website_helpdesk_forum, website_helpdesk_slides - requires https://github.com/odoo/odoo/pull/248061 --------------- This commit clears up the `-webkit-line-clamp` handled in CSS and replace them with the `.o_line_clamp` CSS class. To clamp a certain amount of line, you can now apply the `.o_line_clamp` class to your element, and assign a value to the `--lines-clamp` CSS variable, which will be used to clamp that number of line. If you don't define this variable on your element, the default value will be used, which is `2`. Example with the new method using the class: OLD WAY: ```CSS overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 3; -webkit-box-orient: vertical; ``` NOW: ```XML <!-- If you don't define `--lines-clamp` it'll clamp `2` lines by default !--> <myElement class="o_line_clamp" style="--lines-clamp: 3;"/> ``` task-5905780