Friday, June 26, 2026
21 changes · 19.0
Resolved issues and error corrections
This update fixes how French PDP e-invoicing data is recalculated so that company or customer detail changes no longer trigger unnecessary processing across all invoices. It helps avoid build issues and improves system performance without changing the user-facing workflow.
Original PR description
- This removes dependency on account move fields to company : Build error 939448 - This removes dependency on account move fields to commercial_partner_id fields (avoid recompute all moves on partner info change) Forward-Port-Of: odoo/odoo#271822 Forward-Port-Of: odoo/odoo#269701
This fixes an issue where opening the website editor at 150% browser zoom could incorrectly switch the page preview to mobile view. The editor sidebar now keeps its intended width, preserving the desktop editing experience for users who use browser zoom.
Original PR description
Steps to reproduce: - Open a website page on Chrome/Firefox. - Set the browser zoom to 150%. - Click Edit. => The website preview switches to mobile view. Before this commit, [1] changed the sidebar to `content-box`, so the `border-start` class added one pixel to `$o-we-sidebar-width`. The sidebar then reached 289px instead of 288px, which made the preview fall below the desktop breakpoint at 150% zoom. After this commit, the sidebar width subtracts the Bootstrap border width so its total width stays at 288px and edit mode keeps the desktop view. [1]: https://github.com/odoo/odoo/commit/181b870c3c6cf28c3eac59a16c36b94ae11ae927 task-6251151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The API documentation tool was updated to avoid a deprecation warning from an underlying documentation library. This helps keep Odoo's documentation generation stable and ready for future library versions without changing business workflows.
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
Receipt deadline calculations now exclude cancelled stock moves, so outdated dates from removed purchase order lines no longer keep a receipt stuck on an old deadline. This helps warehouse and purchasing teams see accurate scheduled receipt dates after order quantities or planned dates change.
Original PR description
Steps to reproduce the bug:
- Create a Purchase Order with 2 products and confirm it
- Note the receipt's deadline (= date_planned of both lines)
- Set the quantity of one PO line to 0
- Update the scheduled date (date_planned) of the purchase order
Problem:
the receipt deadline does not update.
The receipt kept the old deadline from the cancelled move. When a PO line qty is set to 0, `_merge_moves` cancels the corresponding stock move via `_action_cancel`. Then `_update_move_date_deadline` correctly skips cancelled moves (filtered by `state not in ('done', 'cancel')`), so the cancelled move retains its original `date_deadline`. However, `_compute_date_deadline` on `stock.picking` used
`move_ids.filtered('date_deadline')`, which not checks move state, so the stale deadline of the cancelled move was included in the min/max computation.
opw-6292600
Forward-Port-Of: odoo/odoo#271530
Forward-Port-Of: odoo/odoo#270985UBL invoice imports now skip valid but empty invoice lines that have zero quantity and zero value. This prevents import failures and avoids confusing error messages for users processing electronic invoices.
Original PR description
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an…
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an import error Such lines are valid UBL but carry no meaningful value, so they are silently skipped after the fix ### Cause: After this commit: https://github.com/odoo/odoo/commit/a7f77f3cfc42764328e7da73a60df8d4cafc968f The `line_extension_amount` was able to go in new parts of the code with a 0.0 value When `line_extension_amount` is set and `invoiced_quantity` is 0, `quantity` is computed as `subtotal * price_quantity / (...)` which resolves to 0 since `subtotal` is also 0 `price_unit = subtotal / quantity` then divides by zero ### Steps to reproduce: - Install `l10n_be` - Import a UBL invoice with a line where `LineExtensionAmount=0`, `InvoicedQuantity=0` and `PriceAmount` is non-zero (You can use the xml on the ticket) Before the fix, the import failed with an error in the chatter opw-6234453 Forward-Port-Of: odoo/odoo#271001
Images placed into device-style shapes now keep the intended shape proportions instead of being forced into a square crop first. This reduces unwanted cropping, especially for tall images such as phone screenshots, making website visuals look closer to what users expect.
Original PR description
Scenario: - insert image with ~ 1:2 ratio (height bigger than width) - set shape "iPhone `#2`" to that image Result: the image should fit without much cropping the 0.46:1 aspect ratio of the shape, but it is cropped 1:1 before being applied to it. Cause: when the image has a set aspect ratio, we are always cropping it to 1:1 aspect ratio in postProcessCroppedCanvas but it should be cropped to the shape aspect ratio as it was done in previous version. Fix: go back to what was done in saas-18.3 and apply the shape aspect ratio and not just square (1:1) aspect ratio. opw-5415137 Forward-Port-Of: odoo/odoo#250922
A test for electronic invoicing partner matching now uses a valid Belgian VAT number while still checking the intended mismatch scenario. This keeps automated testing reliable on newer system versions that apply stricter VAT validation rules.
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
This update prevents private project tasks from being selected as parent tasks. It helps keep task structures consistent and avoids exposing or linking private work in broader project hierarchies.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#271896 Forward-Port-Of: odoo/odoo#270795
This update removes an unnecessary internal status assignment during self-order processing. It helps keep the checkout flow simpler and reduces the chance of confusing or redundant order handling without changing the customer experience.
Original PR description
Remove useless assignation of state from frontend in `_check_pos_order` because its overrided just after in the process.
The German SKR03 accounting template now uses the correct default accounts for cash discounts. This helps German companies start with accurate accounting settings and reduces the risk of misclassified discount entries.
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 fix corrects how Luxembourg accounts classify current-year earnings and simplifies how brought-forward profit or loss is calculated on balance sheet reports. It helps ensure Luxembourg financial statements present the right balances in the appropriate sections.
Original PR description
This commit addresses the account type for the current year earnings and simplifies the calculation for the "Result brought forward" line in the Luxembourg balance sheet reports.
Modifications:
* Changed the account type of account 142 ("Result for the financial year") from `equity_unaffected` to standard `equity`.
* Simplified the formula for the Balance Sheet line "Profit or loss brought forward" (codes `LU_BS_319` and `LU_BSABR_319`).
* The new formula simply targets the `14` accounts while explicitly excluding `142`.
Enterprise PR: odoo/enterprise#121891
Ticket [link](https://www.odoo.com/odoo/project.task/6059571)
opw-6059571This fixes a small issue where one stock filter could replace another instead of working alongside it. Stock quantity history views will now apply all intended product conditions, improving accuracy without changing user workflows.
Original PR description
Description of the issue/feature this PR addresses: During a previous refactoring, the additional domain was assigned instead of being combined with the existing domain, causing the original domain to be overwritten. Current behavior before PR: The existing domain is replaced, so only the product template domain is applied. Desired behavior after PR is merged: The product template domain is combined with the existing domain using an AND operation, ensuring that both domain conditions are applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated test for French PDP invoicing so it works when only the standard Invoicing app is installed. It avoids expecting a payment status that is only available in the enterprise Accounting app, helping keep validation reliable across Odoo editions.
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 restores a website builder setting that prevents users from changing the number of columns in certain predefined layouts. It helps keep intended page designs intact after a previous refactoring accidentally removed this behavior.
Original PR description
The class 's_nb_column_fixed' was used to hide the column count option, but it got lost during the refactoring and doesn't work since 18.4. This commit restores it. task-6234267 Forward-Port-Of: odoo/odoo#268005
This update adjusts an automated accounting test so it only expects taxes linked to a fiscal position to be removed by the unit fiscal position. Taxes that are not tied to any fiscal position are now correctly preserved, making the test reflect the intended behavior more accurately.
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
The Shop Floor view now correctly sorts manufacturing orders with unplanned work orders after those that are already planned. This brings the Shop Floor ordering in line with the rest of Manufacturing, making it easier to focus on the work that is ready to be executed.
Original PR description
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will…
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end. ## Steps to reproduce (runbot 19) 1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B. 2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id 3. Go back to MO B and plan it. This should give it precedence in Shop Floor 4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list. opw-6303323
This update makes the UNSPSC code 10171500, “Organic fertilizers and plant nutrients,” available again in product accounting. It ensures users can find and use the correct classification code when managing products.
Original PR description
The code 10171500 - Organic fertilizers and plant nutrients wasn't appearing. In the file that has the unspsc product codes this one is set to False. Steps to reproduce: - Activate module product_unspsc. - Go to product > accounting. - Verify that this code is not listed. Ticket [link](https://www.odoo.com/odoo/project.task/4461974) opw-4461974
This change fixes a test in the salary configuration flow by ensuring the employee’s private address is available when the test runs. It helps keep the test suite reliable and prevents false failures unrelated to the actual salary configuration behavior.
Original PR description
Task-6329628
This update fixes several issues in the website rental flow tests so they run consistently. It ensures payment setup is only prepared when the needed demo data exists, allows rental scenarios that include weekends, and narrows the shop page search so the right product is found reliably.
Original PR description
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue…
## [FIX] website_sale_renting_planning: prepare payment if demo is installed Before this commit, the demo `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup. After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared. https://runbot.odoo.com/odoo/runbot.build.error/940273 ## [FIX] website_sale_renting_planning: unforbid weekend in tests Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday. This commit fixes that but setting `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week. https://runbot.odoo.com/odoo/runbot.build.error/940312 ## [FIX] website_sale_renting_planning: search for product in shop page Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page. After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page. https://runbot.odoo.com/odoo/runbot.build.error/940275
The Timesheets grid now shows the correct status color for a row even when an employee’s work schedule includes fractional hours. This prevents misleading orange or red indicators caused by tiny rounding differences, so users can trust the visual status shown for completed time entries.
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. This confirms authorization to contribute to Odoo on Codeforward's behalf and supports upcoming work under the established agreement.
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