Daily updates from Odoo
Monday, October 6, 2025
8 changes · 17.0
Resolved issues and error corrections
The message shown after fetching bank transactions now displays correctly instead of showing raw formatting code. This makes the banking workflow clearer for users when no matching transactions are available.
Original PR description
Before this commit : - The help message shown when no transactions were fetched by the 'Fetch Transactions' button in the 'Bank' journal contained raw html tags, as markup was not getting applied. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with markup applied. task-4942234
This fix improves how calendar views appear when dark mode is enabled. It helps users read and navigate calendar information more comfortably by correcting visual styling issues.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes visual issues in dark mode for the manufacturing work order display. It helps ensure production teams can read and use the screen comfortably when dark mode is enabled.
Fixed an issue where one-day time off requests could appear as multi-day events in the Calendar app for users in certain time zones. This helps employees and managers see accurate leave schedules and avoids confusion when planning coverage.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817
This fixes an internal automated test for bus notifications that could fail unpredictably. The test now checks all received notifications, helping keep validation runs stable without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clears invalid saved device identifiers before sending UK tax report requests to HMRC. It helps prevent repeated submission failures caused by outdated or corrupted browser-stored values.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086
Delivery slip reports using the DIN 5008 layout now show ordered and delivered quantities in the correct column alignment. This makes printed or downloaded delivery documents easier to read and more professional for warehouse teams and customers.
Original PR description
**Steps to reproduce:** 1.Install Stock and l10n_din5008 modules. 2.Change the document layout to DIN 5008. 3.Create a Delivery/Picking with two stock moves: - First product without `Description for Delivery Orders` - Second product with `Description for Delivery Orders` 4.Download/Print the Delivery Slip. 5.Observe the quantity alignment in the report. **Issue:** - The Ordered and Delivered quantity columns are misaligned in the Delivery Slip report. **Solution:** - Add a CSS class to properly align the quantity columns in the Delivery Slip. --- **After Fix** <img width="735" height="290" alt="image" src="https://github.com/user-attachments/assets/69a941ff-a3a6-4e9a-993f-ad26af714b18" /> **Before Fix** <img width="757" height="274" alt="image" src="https://github.com/user-attachments/assets/7a4d0f78-112b-47ad-9037-da97e0399c8f" /> --- **opw- 4904727** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now applies quantity-based pricelist rules correctly when the same lot-tracked product is split across multiple lots. This prevents customers from missing eligible pricing when their total purchased quantity meets the rule threshold, even if it appears on separate POS lines.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920