Friday, June 26, 2026
11 changes · saas-19.1
Resolved issues and error corrections
This change adjusts an automated test in Point of Sale so it no longer mixes data from different company setups. It helps prevent test failures caused by company-specific settings and keeps the test environment more reliable.
Original PR description
Making the test only depend on one class setup to avoid potential (already present) multicompany issues. In this case the env.user came from one setup class but was incompatible to use during the setup of the second class that was creating records for another company. By making the test only depend on one of the tests we'll avoid this issue. runbot-939375
This update corrects a Belgian VAT number used in an automated test so it passes under newer validation rules. It keeps the test’s original purpose intact by still checking for a VAT mismatch, but with a valid VAT format.
Original PR description
This commit fixes a Belgian VAT validation check in `test_import_partner_retrieval_bank_account_number` as the provided vat number isn't a valid one. It keeps the spirit of the test by still having vat number mismatch, but with a valid value. The python-stdnum library used for this validation added a stricter check since version 2.2, which is used in Ubuntu Resolute 26.04. References: - https://github.com/arthurdejong/python-stdnum/commit/7ca9b6ce7b1f2b4d1bf164c2af83a8a77bc919d2 runbot-939796 Forward-Port-Of: odoo/odoo#272082
The default account codes used for cash discounts in the German SKR03 setup have been corrected. This helps ensure new company configurations use the proper accounting accounts from the start.
Original PR description
The default cash discout accounts referenced in the
German skr03 template used the wrong account codes.
The template has been updated with the right ones.
task-4915939
opw-4909059
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#271886
Forward-Port-Of: odoo/odoo#271024This update corrects a test in the accounting reports area so it properly handles taxes that are not linked to any fiscal position. It ensures the test only checks that taxes tied to a fiscal position are removed, while unrelated taxes continue to pass through as expected.
Original PR description
map_tax on an empty fiscal position now preserves taxes with no fiscal_position_ids. Filter those out in test_tax_unit_auto_fiscal_position so the assertion only checks that taxes bound to a fiscal position are dropped by the unit FP. comunity PR: https://github.com/odoo/odoo/pull/268273 task-id 623151 Forward-Port-Of: odoo/enterprise#121525
Fixed an issue where the Time Spent cell could show the wrong color in Timesheets when an employee’s working schedule includes fractional hours, such as 8 hours 20 minutes. The update makes the status display reliable so users see the correct green, orange, or red indicator based on actual working time.
Original PR description
## Issue In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color…
## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.
## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
- Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__
## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157
We obtain the following values:
```js
> monday = section.cells[1]
> monday.value
8.333333333333336
> workingHours[monday.column.value]
8.333333333333332
> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```
This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172
## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.
opw-6193181
Forward-Port-Of: odoo/enterprise#121463We fixed an intermittent issue in chat-related tests where the window title could be missed during loading. This makes automated checks more stable and reduces the chance of false failures in messaging features.
Original PR description
The hoot `:text('X')` pseudo-class matches an element only when its whole inline text equals "X". `.o-mail-ChatWindow:text('slytherins')` therefore matched the chat window only during the brief frame where it showed nothing but its title, before the thread body (start message, composer) was rendered. Catching that frame is a race, so the assertion times out intermittently on runbot.
Assert against the title element itself: add a dedicated `o-mail-ChatWindow-name` class on it and match it with `.o-mail-ChatWindow-name:text('X')`. This is exact and no longer depends on the rest of the window being empty.
https://runbot.odoo.com/odoo/error/939914When a pricelist uses a fixed price, Odoo now hides the extra price badge for product variants in both Sales and Website Sales. This avoids showing an additional price that does not actually affect the final price, making pricing information clearer for users and customers.
Original PR description
Issue: --- If pricelist.compute_price is fixed, extra price of variant is not taken into calculation, but it's shown in extra price badge. Steps to reproduce: --- 1- Create a product template with two variants. 2- Apply extra price for each attribute values. 3- Apply a pricing with a fixed price for the product on a pricelist. 4- Create a SO and apply the pricelist. Add the product to SOL. 5- Open product configurator on SOL. - As you see, the extra price is shown but it's not effective. 6- Open the product in website with the pricelist. - Here also the extra price is shown but it's not effective. Cause: --- This is caused because there is no mechanism to hide extra price having pricelist.compute_price == fixed. Fix: --- We need to fix the issue both in sale and website_sale separately by having a flag to ensure extra price badge is hidden if compute_price is fixed. opw-6276208 Forward-Port-Of: odoo/odoo#270140
This change updates the internal documentation generation process to avoid a warning from a third-party library. It helps ensure the feature continues to work smoothly with newer library versions and reduces the risk of future compatibility issues.
Original PR description
Using `Publisher.set_components()` triggers a `PendingDeprecationWarning` stating that the method will be removed in Docutils 2.0. This commit fixes the warning by passing the component names (`reader`, `parser`, and `writer`) directly into the `Publisher` constructor during instantiation, ensuring compatibility with upcoming Docutils versions. runbot-940246 Forward-Port-Of: odoo/odoo#272117
This update corrects an automated test for the French e-invoicing feature so it no longer expects a payment status that is only available in the Enterprise accounting app. It helps ensure the Community version builds and tests successfully when only Invoicing is installed.
Original PR description
The `in_payment` state does not exist in community with only the Invoicing module installed. It is added in `enterprise` in the Accounting module. runbot.build.error-939451 Forward-Port-Of: odoo/odoo#267475
This update fixes a failing automated test related to French leave management. It adds a safe fallback for the user time zone when it is not available during test runs, preventing avoidable errors in Odoo’s automated validation environment.
Original PR description
Currently the test test_holiday_in_week is failing in runbot tests This is due to the fact that during the tests the user tz in env is not set and hence it fails in the pytz library. Added a fallback to avoid the issue runbot issue opw-237623 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 Forward-Port-Of: odoo/odoo#248941
Documentation and clarification updates
This change adds Djody Kort to the contributor list under Codeforward B.V.'s existing Corporate CLA. It ensures the upcoming contribution is properly covered and authorized on behalf of the company.
Original PR description
Adds me (Djody Kort) to the contributor list of the existing Codeforward B.V. Corporate CLA (`doc/cla/corporate/codeforward.md`). This precedes an upcoming `[FIX] service/server` bug-fix contribution. Codeforward's Corporate CLA v1.0 is already on file (signed by Sander Lienaerts), and I am authorized to contribute on Codeforward's behalf. Forward-Port-Of: odoo/odoo#269240