Monday, December 23, 2024
6 changes · 18.0
Resolved issues and error corrections
This update prevents crashes when the Peppol invoicing module is updated before a related invoicing component. It keeps partner contact pages working reliably during staggered module updates.
Original PR description
In case `account_edi_ubl_cii`is not updated, but `account_peppol` is updated, it will crash as `id="peppol_address"` div does not exist yet. task-no
Fixes a communication issue where point-of-sale customer display status requests were missing required request details. This helps the IoT Box understand the request correctly, improving reliability of connected customer displays.
Original PR description
Customer display "get" action was missing `params` key, required for the IoT Box to understand the request correctly.
Fixes a chat behavior where pressing Escape while an emoji reaction menu was open could close the entire chat window instead. This makes message reactions feel more predictable and also restores the reaction tooltip after closing the menu.
Original PR description
Before this commit, when opening message reaction menu in a chat window, clicking on ESC was closing the chat window. Steps to reproduce: - as Mitchell Admin, open a chat window of channel General…
Before this commit, when opening message reaction menu in a chat window, clicking on ESC was closing the chat window. Steps to reproduce: - as Mitchell Admin, open a chat window of channel General from click on messaging menu in systray - add an emoji reaction to the last message - click on composer to have focus on it - mouse hover the reaction then click on emoji reaction tooltip - press ESC when the message reaction menu is open => it closes the chat window instead of message reaction menu. This happens because when opening the message reaction menu, the dialog is mounted. It detects dropdown is closed after a delay, and when closing the dropdown it recovers the focus before the opening of dropdown, which could be the composer of chat window. In the case when the focus was on composer, pressing ESC on message reaction menu will close the chat window due to composer being focused. This commit fixes the issue by immediately setting the dropdown state to close when clicking to open message reaction menu, so that it won't recover the old focused element such as the composer. --------- This commit also fixes a related minor bug when closing the message reaction menu then hovering the reaction was not showing the dropdown/tooltip of reaction. This happens because the `useHover()` hook was not aware the click on dropdown content closes the hovered ref, thus it kept internally thinking the item is hovered so it wasn't updating UI to open dropdown or reaction. This is fixed by adding a parameter `stateObserver` to help the `useHover()` hook to re-check whether the targets are present on UI. Thanks to this, it can detect whether the currently hovered target has been removed, thus invoking the behaviour to mark is as no longer hovered. task-4351992 Before  After 
The Mexican DIOT tax report now correctly provides the date filter information expected by the reporting interface. This prevents users from seeing an error when opening or using the tax return report filters, improving reliability for Mexican localization reporting.
Original PR description
The error in question was caused by the MX localization MexicanAccountReportCustomHandler DIOT report model neither including tax_periodicity in it's own _custom_options_initializer() which overrides the version inherited from account_generic_tax_report.py, therefore account_reports/static/src/components/account_report/filters/filters.js -> hideTaxPeriodFilter() showed an error when trying to get it. task: 4402723
This fix keeps the WhatsApp discussion experience aligned with recent Discuss app changes. The member panel now opens by default as expected, reducing confusion for users who manage or follow conversations.
Original PR description
Member panel is open by default in discuss app https://github.com/odoo/odoo/pull/191293
This fixes an error that prevented users from opening an employee's payslips when their attendance-based contract had no working schedule set. Payroll now safely uses another available timezone, falling back to UTC, so payslip access remains reliable for fully flexible contracts.
Original PR description
**Issue:** The client gets an error while accessing an employee's payslips if that employee has a contract based on attendances with a null allowed value for its working schedule. **Expected:** The…
**Issue:** The client gets an error while accessing an employee's payslips if that employee has a contract based on attendances with a null allowed value for its working schedule. **Expected:** The client should be able to access the payslips regardless on the working schedule value, even blank. **Steps to reproduce:** - Activate Payroll app and presence based on attendances in employees' settings; - Open or create a contract through an employee's file; - Set "Work Entry Source" to "Attendances" and leave "Working Schedule" empty; - Try to access the employee's payslips through the action button. **Cause:** No timezone found on a contract's calendar because the calendar is null. [https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141](https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141 ) **Fix:** Add a default value on `'UTC'` if no calendar has been found. **Linked:** Community PR : https://github.com/odoo/odoo/pull/186222 opw-4268672