Friday, July 3, 2026
17 changes · 18.0
Resolved issues and error corrections
This update fixes an issue that prevented users from clearing the date field in the WIP Accounting Entry wizard, which was causing errors. The change ensures the wizard functions correctly when temporarily emptying the date field, improving user workflow and data accuracy.
Original PR description
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the…
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard. Steps to Reproduce: - Open the list view of Manufacturing Orders. - Open the Post WIP Accounting Entry wizard by either: - Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry - Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu. - Clear the Date field. - Observe that an error is raised. Cause of the Issue: The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error. With This PR: The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input. Issue reference: https://github.com/odoo/odoo/issues/246547
This update fixes an issue where the Intrastat report was incorrectly cropping the bill name, preventing full visibility of key information like the hyphenated identifier. The fix adjusts a regex pattern to now correctly handle hyphen characters in bill names, ensuring accurate reporting and data display. This improves the clarity and usability of the Intrastat report.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] * Intrastat Country: [any] * Intrastat Transport Mode: [any] - Confirm the bill - Make sure that the bill name contains a hyphen character (i.e. "-") For example, "BILL/2026-06/0001". Use the "Resequence" action from the bills list view if needed. - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Expand the line to display the bill name **Issue:** The bill name is not fully displayed. It is cropped right before the hyphen character (i.e. BILL/2026). **Cause:** A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character. **Solution:** Just allow "-" character in addition. No other character is allowed to limit the risk of matching something that should not. opw-6299854
This update resolves a bug where recurring events synced from Google Calendar were sometimes duplicated, particularly when Google's 'UNTIL' date was set in UTC. The fix ensures Odoo correctly handles recurrence boundaries, preventing the creation of extra events that don't exist in Google Calendar. This ensures accurate event scheduling for users across different time zones.
Original PR description
When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created. Steps to reproduce: 1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local). 3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day). 4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar. opw-6024835 Forward-Port-Of: odoo/odoo#265297
This update fixes a technical issue preventing the Gantt view from correctly displaying task progress for sales orders. The fix ensures that the system accurately calculates and displays planned hours when grouping tasks by sale order item, resolving a previous migration-related error.
Original PR description
### Steps to reproduce - Install `sale_timesheet_enterprise`. - Go to **Tasks → All Tasks**. - Switch to the **Gantt** view. - Group by **Sale Order Item** (`sale_line_id`). ### Issue A traceback is…
### Steps to reproduce - Install `sale_timesheet_enterprise`. - Go to **Tasks → All Tasks**. - Switch to the **Gantt** view. - Group by **Sale Order Item** (`sale_line_id`). ### Issue A traceback is raised when loading the Gantt view with group by `sale_line_id`: ```text ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum' ``` ### Root cause The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`. However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`. Migration reference: https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10 Issued PR: https://github.com/odoo/enterprise/pull/49685 ### Fix Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback. Forward-Port-Of: odoo/enterprise#122297
This update fixes a visual issue where progress on Gantt chart task pills was appearing very faint. The underlying code change standardized progress calculations, but a key view (Gantt) was missed. The fix ensures the progress bars accurately reflect the allocated time, improving task visualization.
Original PR description
Steps to reproduce: ------------------------------------------- 1. Install the Timesheet module with demo data 2. Go to any FSM task > set allocated hours to 20h 3. Fill the timesheet for the same…
Steps to reproduce: ------------------------------------------- 1. Install the Timesheet module with demo data 2. Go to any FSM task > set allocated hours to 20h 3. Fill the timesheet for the same task for 10h 4. Navigate to FSM > My Tasks > Gantt view Observation: ------------------------------------------- Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50% Issue: ------------------------------------------- In the commit https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed. Solution: ------------------------------------------- Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module. Before --------------------------- <img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" /> After: -------------------------- <img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" /> opw-6038983
Example of steps: - Install web_studio and `accountant` - Open the corresponding form view in Studio - With debug mode toggle "Show invisible Elements" and edit "Invisible" on the second partner_id field - Traceback `normalize()` compares the combined arch without the studio customization to the one with it, in order to compute the smallest possible set of xpaths. To do so, it calls `apply_inheritance_specs` (the low-level function from `odoo.tools.template_inheritance`) directly on the s
Original PR description
Example of steps: - Install web_studio and `accountant` - Open the corresponding form view in Studio - With debug mode toggle "Show invisible Elements" and edit "Invisible" on the second partner_id…
Example of steps: - Install web_studio and `accountant` - Open the corresponding form view in Studio - With debug mode toggle "Show invisible Elements" and edit "Invisible" on the second partner_id field - Traceback `normalize()` compares the combined arch without the studio customization to the one with it, in order to compute the smallest possible set of xpaths. To do so, it calls `apply_inheritance_specs` (the low-level function from `odoo.tools.template_inheritance`) directly on the statically combined arch. Some models add or duplicate nodes dynamically in `_get_view()` (Python postprocessing, run after the static view combination). A studio operation can target such a node, since it is what the user actually sees and clicks on. But that node has no counterpart in the purely static combined arch used by `normalize()`, so `apply_inheritance_specs` raises a ValueError. `edit_view()` only catches `ValidationError` to fall back to an un-optimized (but valid) studio arch instead of failing the request. Since the low-level function raises a plain `ValueError` here, that fallback never triggers, and the exception is not caught anywhere. To fix this, we will keep the behavior from version 18.0 and catch the ValueError raised by `apply_inheritance_specs` in `normalize_with_keyed_tree` and re-raise it as a ValidationError, like `ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets `edit_view()`'s existing fallback handle the case gracefully instead of crashing. opw-6332911
This update resolves an issue where draft and cancelled invoices were incorrectly labeled with 'PROFORMA' when not posted. This change ensures that PDF invoices generated for these states are accurate and consistent, improving the user experience and report generation. The fix was driven by a specific user request (opw-6300163).
Original PR description
**Steps to reproduce:** - Create an invoice - Do not post it - Download PDF through the cog Actions icon - Cancel the invoice - Download PDF through the cog Actions icon **Issue:** The draft and cancelled invoices are prefixed with PROFORMA. PROFORMA on a invoice that is not posted doesn't make sense. opw-6300163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug by storing the number of replies from Twitter/X posts within Odoo. Now, users can see the total number of comments alongside other engagement metrics for Twitter posts, providing a more complete view of performance. This enhancement ensures accurate reporting on Twitter activity.
Original PR description
Twitter/X tweet metrics returned by the API include the number of replies in the `public_metrics.reply_count` field. This commit stores that value on social stream posts so the comments count can be displayed alongside other engagement metrics. API Documentation: https://docs.x.com/x-api/fundamentals/metrics#post-metrics Task-6251172
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods multiple times for related field updates. This change reduces redundant calls, resulting in faster form loading and a smoother user experience. It's a small but important performance enhancement.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251813
This update corrects a formatting issue in Chilean export invoices where data was incorrectly aligned in the customs information table. The fix ensures that all columns remain in the correct position, regardless of whether the 'Origin Port' or 'Destination Port' fields are populated. This prevents data from appearing under the wrong column headings, improving invoice accuracy.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670
This update optimizes how Odoo tracks email interactions within the Knowledge base. The change adjusts query counts based on a new savepoint mechanism introduced during email sending, leading to more efficient data processing and improved performance. This results in faster response times when accessing knowledge articles.
Original PR description
Related to https://github.com/odoo/odoo/pull/272958
This update ensures the Account EDI Proxy Client is configured for demo environments only, aligning with the existing setup in the account_peppol module. This prevents unintended use with production data and simplifies testing within the demo system. It corrects a configuration issue that was causing the proxy client to incorrectly target production users.
Original PR description
The system parameter is already brought to demo in account_peppol module. But the current users are not for pdp. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test failure related to holiday accrual calculations in the HR module was caused by a discrepancy in how dates were being handled in future builds. This fix adds a temporary 'freeze time' to the 2026-03-01 date, ensuring accurate accrual calculations moving forward. This prevents incorrect holiday allocation figures.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 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
This update clarifies extra hours reporting by renaming confusing labels like 'Difference' and 'Balance' to 'Worked Extra Hours' and 'Validated Extra Hours'. This change ensures consistent and understandable reporting across all Odoo HR attendance views, improving data clarity for users.
Original PR description
The reporting labels "Difference" and "Balance" are confusing because "Difference" tracks system-qualified overtime while "Balance" represents accepted overtime hours. There is also a lack of consistency across views. This commit renames these fields to "Worked Extra Hours" and "Validated Extra Hours" to harmonize the naming everywhere task-6352142 Description of the issue/feature this PR addresses: Confusing and inconsistent naming for extra hours Current behavior before PR: - Reporting uses "Difference" and "Balance". - Views use inconsistent labels. Desired behavior after PR is merged: Labels are consistently named "Worked Extra Hours" and "Validated Extra Hours" everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual issue in the account module where the dropdown for account types remained in light mode when dark mode was enabled. The change ensures the dropdown background matches the dark mode theme, providing a consistent and professional user experience. This improves visual consistency across Odoo's interface.
Original PR description
Steps to reproduce: - Install `account` module - Enable dark mode - Open `view_account_form` to create a record - On the Accounting page, open type dropdown - The dropdown background remains in light mode This commit applies $dropdown-bg on `o_field_account_type_selection` as in odoo/odoo@0cd148eb389078c896aaa719af5733d05377fd1c Forward-Port-Of: odoo/odoo#271352
This commit addresses a minor issue with a test related to the l10n_it_edi_withholding module. The change ensures the test accurately reflects the functionality of a previously merged PR. This ensures the ongoing stability and reliability of the Italian tax reporting feature.
Original PR description
This commit just want to correct a test of a PR already merged. Original commit: 78ffb5a2e63401123e4506056493e52cf3e69953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a performance issue in the Point of Sale system. Previously, fetching order data involved multiple, separate requests, which slowed down the system. The change combines these requests into one, resulting in faster order retrieval and a smoother user experience.
Original PR description
Issue: pos_self_order overrode getServerOrders() to add a separate loadServerOrders() call for it's own orders before delegating to super, resulting in up to an additional sequential RPCs on every order fetch. Fix: Extract the base query domain into a new overridable getServerOrdersDomain() method. Each module overrides it to OR in its own domain via Domain.or([super.getServerOrdersDomain(), extraDomain]), so all orders are fetched in a single RPC call instead of three. Task-6284860 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