Friday, September 4, 2026
5 changes · 18.0
Resolved issues and error corrections
This fix removes sample budget data that depended on a separate purchasing component not always installed with project budgets. It helps prevent setup or demo database errors for companies using project budget features without that purchasing module.
Original PR description
This commit removes demo data referencing the module `project_purchase` as there is no direct dependency chain from `project_account_budget` to `project_purchase`. [error-237905](https://runbot.odoo.com/odoo/error/237905)
This fixes noisy false-positive messages during Odoo test runs on Windows by handling file paths consistently across operating systems. It does not change business functionality, but helps developers get clearer test results and reduces distractions during quality checks.
Original PR description
## Summary Normalizes the path returned by `inspect.getsourcefile(caller)` in `odoo.tests.common.TransactionCase.setUpClass()` before the existing suffix checks are evaluated. ## Problem The…
## Summary
Normalizes the path returned by `inspect.getsourcefile(caller)` in `odoo.tests.common.TransactionCase.setUpClass()` before the existing suffix checks are evaluated.
## Problem
The `MetaModel.__setattr__` test checker added in 18.0 compares `filename.endswith(...)` against slash-based suffixes such as `odoo/models.py` and entries in `SETATTR_SOURCES`.
On Windows, `inspect.getsourcefile()` returns backslash-separated paths, so legitimate internal calls can miss those allowlist checks and produce noisy false-positive logging during tests and cleanup.
## Fix
Normalize the inspected path once with:
```python
filename = (inspect.getsourcefile(caller) or '').replace('\\', '/')
```
This keeps the existing logic unchanged while making the suffix checks platform-neutral.
## Validation
- Reproduced the noisy Windows behavior locally on 18.0.
- Verified the one-line patch removes the false-positive teardown logging in local test runs.
- Syntax-checked the modified file with `py -3.12 -m py_compile odoo/tests/common.py`.The project list now shows the upcoming milestone based on the milestone deadline instead of creation order. This keeps the project overview aligned with the milestone list and avoids confusion when tracking project progress.
Original PR description
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent…
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent with the milestone list. Steps to reproduce: - Create a project with milestones enabled. - Create MS1, then MS2. - Give MS1 a later deadline than MS2. - Open the project list and display the Next Milestone column. Cause: `_compute_next_milestone_id()` aggregated unreached milestones as an `id:recordset` and selected its first element. The ORM orders that aggregate by database ID, so creation order was used instead of the milestone model's deadline order. https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/addons/project/models/project_project.py#L209-L218 https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/odoo/models.py#L364-L377 Solution: Retrieve unreached milestones through their normal ordered search before grouping them per project. This preserves batched computation while ensuring that the selected record follows the established milestone order. opw-6496938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The spreadsheet insertion dialog no longer shows unnecessary horizontal scrolling or duplicate scrollbars on smaller screens. This makes the dialog easier to use and keeps its layout consistent across spreadsheet-related areas.
Original PR description
Opening "Insert in Spreadsheet" displayed an unwanted horizontal scrollbar in the spreadsheet selector. On small viewports, it could also produce a second scrollbar alongside the scrollable modal. The selector reused the `o-spreadsheet-templates-dialog` class, whose styles belong to `documents_spreadsheet`. This applied template-only max-height and overflow rules to the selector and made `spreadsheet_edition` rely on styles from a dependent module. Give selector dialogs their own class and keep the template-specific styles on the template dialog. Move the shared pager layout to `spreadsheet_edition` under a dedicated class, and update both pager consumers and the dashboard document selector. Task: 6526781
Bold formatting in blog articles now appears visibly distinct even when the surrounding text uses a light font style. This helps authors and readers see emphasized text as intended in website blog content.
Original PR description
Problem: When a parent element applies a `font-weight: 300` to its content, a child `<strong>` tag defaults to `font-weight: bolder`, which resolves to a computed font weight of `400`. For certain font families, weight `400` is visually identical to `300`, leaving no visual distinction for bold text. Cause: `<strong>` tags relied on relative weight boosting (`bolder`), which only increases the parent weight from `300` to `400` instead of applying explicit bold weight. Solution: Explicitly set `font-weight: bold` on `strong` for `.o_wblog_read_text` Steps to reproduce: - Go to /blog - Open any blog - Open editor. - Select some text from the content of the blog. - Apply Bold. - Observe that there is no visual difference. opw-6460699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr