Friday, June 26, 2026
7 changes · saas-18.2
Resolved issues and error corrections
A test case was updated to use a valid Belgian VAT number while still checking that mismatched VAT details are handled correctly. This prevents automated validation failures caused by stricter third-party VAT checks in newer system environments, improving release reliability without changing user-facing behavior.
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 disconnect button for France electronic invoicing now uses the correct label instead of referring to Peppol. This reduces confusion for users managing French e-invoicing settings.
Original PR description
The name of the disconnect button for the France e-invoicing was incorrect as it referenced peppol and was fixed in this pr to be called Disconnect French electronic invoicing task-6266337
Users can now edit purchase order line descriptions after a purchase order is confirmed, as long as the order is not in a final locked state. This removes an inconsistent behavior where the field became read-only depending on whether the product column was visible.
Original PR description
Steps to reproduce the bug: - Create and Confirm a purchase order with any product and a description (name) on the order line - Try to edit the description (name) field Problem: The description field…
Steps to reproduce the bug:
- Create and Confirm a purchase order with any product and a description (name) on the order line
- Try to edit the description (name) field
Problem:
The description field was not editable on a confirmed purchase order when the product_id column was visible, but became editable when product_id was hidden.
The `ProductLabelSectionAndNoteField` widget renders both `product_id` and the description (`name`) in a single cell. When `props.readonly` is true (because `product_id` has `readonly="state in ('purchase', 'to approve', 'done', 'cancel')"`) and the order state is not draft (`isProductClickable` is true), the template rendered the description textarea with a hardcoded `readonly="1"` attribute, making it impossible to edit regardless of the actual intended readonly state for the description.
When `product_id` was column-invisible, the `name` field rendered via its own `section_and_note_text` widget, which correctly used `sectionAndNoteIsReadonly` (blocking only `cancel`, `done`, `posted`) hence the inconsistency.
Solution:
Replace `readonly="1"` with `t-att-readonly="sectionAndNoteIsReadonly"` on the description textarea so its editability follows the same logic as the other cases: blocked only for terminal states (`cancel`, `done`, `posted`), not for `purchase` or `to approve`.
opw-5474986
Forward-Port-Of: odoo/odoo#272102A test was corrected so it no longer expects a payment status that is only available with the full Accounting app. This helps keep automated checks reliable for community setups using only Invoicing, reducing false build failures.
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 fix prevents Romanian electronic stock batch rules from being applied in situations where they do not belong. It avoids automated test failures and reduces the risk of unintended behavior for companies outside the Romanian localization flow.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098
This change corrects the color shown in the Time Spent cell when an employee’s schedule includes fractional hours. It prevents valid timesheets from being flagged with the wrong status because of tiny rounding differences.
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#121463Documentation and clarification updates
Djody Kort has been added to Codeforward B.V.'s existing corporate contributor agreement record. This keeps contribution authorization records up to date ahead of planned future work, with no impact on product behavior.
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