Odoo Changelog — 2025-12-30

Tuesday, December 30, 2025

3 changes · 18.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] point_of_sale: correctly add the scanned product

Core18.0point_of_sale

This update fixes an issue where scanning invalid GS1 barcodes in Point of Sale could incorrectly load products. Previously, scanning a barcode like '0000' would lead to the first product containing '0' in its barcode being loaded. This change ensures that only valid barcodes correctly identify and add the intended product to the sale.

Original PR description

Before this commit, when GS1 barcode was set in the company settings, scanning an invalid barcode may load a wrong product. For example, if the barcode "0000" was scanned, and it would search for all products that contains "0" in their barcode, and load the first one found.

opw-5394561

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#barcode#pos#product

[FIX] l10n_be_hr_payroll: fix traceback when creating a payslip

PR #99217

Enterprise18.0l10n_be_hr_payroll

This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in the Belgian payroll system. The fix ensures that the system now defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation.

Original PR description

Currently, a traceback occurs when a user tries to create a payslip for a contract 
that has no working schedule in a Belgian company.

**Steps to reproduce this issue:**

1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 
2) Create an employee with no working hours.
3) Create a contract for that employee with:
   - Work entry source as Attendance
   - No Working Schedule
   - State should be open/running 
4) Click the Payslip smart button to create a new payslip for that contract. 
5) A traceback occurs

**Error:**
```
ValueError: Expected singleton: resource.calendar()
```
**Cause:**
When creating a payslip for a contract with no resource_calendar_id, 
the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` 
through self.resource_calendar_id. Since the contract's calendar lacks a 
resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472

**Solution:**
If the contract or employee does not have a resource_calendar_id, 
use the default resource_calendar_id from the company instead.

opw-5237559

#payroll#belgium#hr#contract

[FIX] mail: fix race condition in partner suggestion sort test

PR #241619

Core18.0mail

This update resolves a sporadic test failure related to how partner suggestions are sorted, specifically when messages are sent. The fix ensures the test accurately reflects the system's data by waiting for the necessary updates to complete before verification, preventing incorrect sorting results.

Original PR description

Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition.

This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3").

This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order.

runbot-237553

#testing#suggestions#sorting

Before this commit, when GS1 barcode was set in the company settings, scanning an invalid barcode may load a wrong product. For example, if the barcode "0000" was scanned, and it would search for all products that contains "0" in their barcode, and load the first one found. opw-5394561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559

Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition. This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3"). This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order. runbot-237553