Daily updates from Odoo
Monday, December 23, 2024
11 changes
1 change
Resolved issues and error corrections
This fix prevents an error when users create or select planning resources that do not have a linked employee. Instead of crashing, the system now safely leaves the avatar empty, allowing planning workflows to continue normally.
Original PR description
Steps to reproduce: --- - Install ``planning`` module - Give the demo user as ``administrator`` in planning. - Log in as Demo user > Go to planning - Click on ``New`` > click on the ``Resource`` field Traceback: --- ``IndexError: tuple index out of range`` The error occurs at [1] because we couldn't find an employee in ``avatar_per_employee_id``. This happens when a new resource is created in the first tab, but the ``employee_id`` is not found in the ``resource`` in the second tab. This commit resolves the above error by returning false if an employee is not present. [1]- https://github.com/odoo/odoo/blob/fb4d758ed78211a61ea797759e1fb3b02b51be60/addons/hr/models/resource.py#L34 sentry-5508268100, 6134007941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
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
4 changes
Resolved issues and error corrections
This update resolves a problem where two Datev export files had the same name, causing confusion and inefficiency. The change ensures distinct file names for each export, streamlining the process and improving data organization. This fix ensures accurate and reliable Datev reporting.
Original PR description
The 2 exports have the same name, which is impractical. Let's differentiate them task-4414223 Forward-Port-Of: odoo/enterprise#75907
This update corrects a minor issue where some labels were missing in English for the Mexican reports module. Specifically, the `l10n_mx_nationality` and `l10n_mx_type_of_operation` fields now have accurate English translations. This ensures proper reporting functionality for users in Mexico.
Original PR description
Add missing english labels for the `l10n_mx_nationality` and `l10n_mx_type_of_operation`fields.  task-no Forward-Port-Of: odoo/enterprise#76038
This update fixes a bug in the account reconciliation process. Previously, the system only flagged discrepancies when the ending balance didn't match the transaction sum. Now, it also identifies issues when the starting balance doesn't align with the previous statement's ending balance, ensuring more accurate reconciliation reports.
Original PR description
### Before The 'Invalid Statements' filter only considered the case of the Ending Balance not matching the Starting Balance + the sum of its transactions. We were not considering the case of the Starting Balance of the statement not matching the previous statement's Ending Balance. ### Now Fixed the condition of the filter to account for the second case. task-4397412
This update corrects a bug that prevented users from accessing CRM leads during testing. The fix ensures proper permission controls are enforced, preventing unauthorized access. This improves the reliability of our CRM test environment.
Original PR description
Fixing permission access error in the test (user does not have access to crm.lead). task-4380712 odoo/odoo#191319 Forward-Port-Of: odoo/enterprise#75965