Monday, August 17, 2026
13 changes · 19.0
Enhancements to existing features
HR users can now see and configure whether each time off type creates a matching Calendar entry. This makes the existing setting easier to understand and helps teams control how leave requests appear in calendars.
Original PR description
The `create_calendar_meeting` field on `hr.leave.type` allows users to choose if leave requests created with a given time off type generate a corresponding entry in the Calendar app. However, this field was not displayed on the form view. This commit adds `create_calendar_meeting` to the `hr.leave.type` form view inside the configuration section, along with dedicated help text explaining its behavior. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282339 Forward-Port-Of: odoo/odoo#280593
Resolved issues and error corrections
The product catalog now handles long unit of measure names without cutting them off or overflowing the layout. This makes sale order product selection clearer for users working with customized or descriptive unit names.
Original PR description
Steps to produce: --- - Install `sales` module. - Go to Settings and enable `Units of Measure and Packaging`. - Set a long name for `units` UoM. - Create a Sale Order and add a product via the…
Steps to produce: --- - Install `sales` module. - Go to Settings and enable `Units of Measure and Packaging`. - Set a long name for `units` UoM. - Create a Sale Order and add a product via the catalog. Issue: --- - Long UoM names are not fully visible in the catalog view. Root cause: --- - The outer `<div>` has `d-flex` but lacks `w-100`, causing it to overflow its container. Solution: --- - Added `w-100` to the outer `<div>` to prevent overflow. - Adjusted the quantity selector layout for better visibility. Before: --- <img width="388" height="141" alt="image" src="https://github.com/user-attachments/assets/dafae08a-3c9d-4163-8894-daa2e4d26f62" /> After: --- <img width="382" height="154" alt="image" src="https://github.com/user-attachments/assets/abd6f034-be4b-49bf-be9c-c9779de0f30d" /> Enterprise PR: https://github.com/odoo/enterprise/pull/121139 opw-6253382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267118
Portal users can now comment on forum answers marked as best answer without being blocked by an access error. The fix ensures notifications only include followers the commenter is allowed to see, keeping the forum discussion flow working for external users.
Original PR description
Steps to reproduce: =================== 1- On a forum add a comment 2- Portal user answer that comment & selected as best answer 3- Protal user2 comment that answer -> access error (See ticket video easier to describe) cause: ====== When commenting on a forum answer, the message post method adds followers of the parent question as `partner_ids`. (See [1]) In 19.0, a new ORM security check requires read access on comodel records when writing to Many2many fields. (See [2]) This caused an AccessError when the user couldn't read all followers (partners). Filter `partner_ids` using `search()` to include only partners accessible to the current user. [1]: https://github.com/odoo/odoo/blob/411c14210668ac6290ef6dc8535770179879b9bc/addons/website_forum/models/forum_post.py#L758 [2]: https://github.com/odoo/odoo/commit/aae732957c3c opw-5357483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an outer table’s text or background color from incorrectly overriding colors in tables nested inside it. Business users benefit from more reliable formatting when editing or importing content with complex tables in the HTML editor.
Original PR description
Problem:
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.
Cause:
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.
Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.
Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.
opw-6438972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#281413German vendor bills printed from self-billing purchase journals now show the correct self-billing header instead of the standard vendor bill header. This helps companies issue compliant documents and reduces confusion for suppliers and accounting teams.
Original PR description
***Steps to reproduce*:** * Install the `l10n_din5008` module. * Set up a German Company and set the fiscal location to Germany. * Select the German company and create a new Purchase Journal. * Enable **Self Billing** for the journal. * Create a vendor bill and print the PDF. ***Observed behavior*:** * The printed document displays the regular vendor bill header instead of the self-billing header. ***Cause*:** * The condition required to display the self-billing header was missing from the report template if self-billing is enabled. ***Fix*:** * Add the missing condition so that the self-billing header is displayed when **Self Billing** is enabled on the journal. * For reference, here is the [Document](https://www.gesetze-im-internet.de/ustg_1980/__14.html) link. Ticket [link](https://www.odoo.com/odoo/project.task/6281066) opw-6281066 Forward-Port-Of: odoo/odoo#272857
This fix prevents an error when a French company using Peppol is disconnected because its configuration is out of sync. It ensures the French Peppol module follows the expected process, helping avoid disruption during account configuration updates.
Original PR description
Fix the function signature of the _reset_peppol_configuration function Step to reproduce: - Install l10n_fr_pdp and register a company on Peppol - When the _peppol_out_of_sync_disconnect_this_database will be called, it will call the _reset_peppol_configuration(soft=True), and since l10n_fr_pdp overrides this function but don't declare the soft parameter, it will raise a TypeError. opw-5728596
The activity view now shows counts that match the records displayed when users first open it. This prevents confusion where the pager showed 100 records but the activity column count only reported 80.
Original PR description
Steps: - Install sale_management - Make sure you have 100 quotations with 1 activity each - Open activity view - Default pager displays `1-100/100` - Activity count display `To-do 80`…
Steps: - Install sale_management - Make sure you have 100 quotations with 1 activity each - Open activity view - Default pager displays `1-100/100` - Activity count display `To-do 80` ActivityController uses `useModel` which passes the raw `component.props` to `model.load()`, including the limit from `ir.actions.act_window` (default 80). This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`, overriding `ActivityModel.DEFAULT_LIMIT` (100). The records list was not affected because `RelationalModel._getNextConfig` never reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100 records correctly. But `fetchActivityData` used 80, causing a mismatch between the records shown and the activity counts in the column headers. ```js export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"]; ``` The fix strips `params.limit` in `ActivityModel.load()` before passing params to `fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager `onUpdate` handler calls `fetchActivityData` directly with its own `params.limit` and is not affected. However, `ActivityController` never forwards `limit` to the model. This is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking into account actions's limit. To fix this we have to add the limit via `this.props.limit`, as `ListController`. `useModelWithSampleData` already had the correct behavior by calling `model.load(getSearchParams(props))` which filters out non-search params like limit. In 19.0 useModel was updated to do the same, so the issue does not exist there. Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697 opw-6281125 Forward-Port-Of: odoo/odoo#280747 Forward-Port-Of: odoo/odoo#273929
The self-ordering flow now checks that combo items belong to the correct parent combo line before accepting them. This prevents incorrect combo relationships in point-of-sale orders, reducing ordering mistakes for customers and staff.
Original PR description
Be sure that combo product of the current line belong to its combo parent line.
The Journal Audit review now removes group headers once all items inside them have been reviewed. This keeps the list tidy and avoids showing confusing empty groups with a zero count.
Original PR description
Currently, in the Journal Audit review, when a user clicks the "Review" button on a grouped list (e.g., a bill), the line item successfully disappears, but the group header remains visible with a count of (0). This leaves unnecessary empty headers cluttering the view. This introduces a custom `DynamicGroupList` that intercepts the data payload in `_setData` and drops any groups with a count of 0. JS tests added for coverage. Task-6377569
The product catalog opened from Field Service tasks now gives more space to the unit of measure column. This makes product information easier to read and aligns the Enterprise interface with the related Community update.
Original PR description
Steps to produce: --- - Install `Field service` module. - Create a task and open it. - From the task open the catalog from smart button. Update the Product Catalog UI to match the Community PR changes. community PR: https://github.com/odoo/odoo/pull/267118 opw-6253382 --- Forward-Port-Of: odoo/enterprise#121139
Project Forecast no longer shows the Time Management section in project settings unless the Timesheets app manages that section. This avoids confusing users with timesheet-related options when the Timesheets app is not installed.
Original PR description
**Steps to reproduce:** - Install the project_forecast module. - Go to Projects -> Open the settings of any project (create one if none exist) -> Settings. - You will see the Time Management section. **Issue:** The project_forecast module was forcefully setting the invisible attribute of group_time_managment to 0. This caused the group to remain visible at all times, even when the Timesheets app was not installed. **Fix:** Remove the forced attribute setting from the project_view. The visibility is already properly managed by the hr_timesheet module, and project_forecast does not depend on timesheet_grid or hr_timesheet. **Merge Till - SaaS-19.1 only, then from SaaS-19.2 : https://github.com/odoo/enterprise/pull/121454** task-6195716 Forward-Port-Of: odoo/enterprise#127802 Forward-Port-Of: odoo/enterprise#121565
This change updates internal subscription-related tests so they remain aligned with related platform changes. It helps maintain reliability of subscription workflows without changing what business users see or do.
Original PR description
See also: - https://github.com/odoo/odoo/pull/280403
The returns kanban view now supports using the up and down arrow keys to move through return selections. This prevents an error that could interrupt users when navigating returns with the keyboard, making the process smoother and more reliable.
Original PR description
In returns kanban view, a traceback occurs when pressing down. Fix this by adding the support for up/down keyboard navigation for returns selection. task-6281033