Monday, July 6, 2026
13 changes · saas-18.3
Enhancements to existing features
The Sendcloud delivery option previously called "Use Batch Shipping" is now called "Use Multicollo". This aligns Odoo wording with Sendcloud terminology and helps customers better understand the setting.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477 Forward-Port-Of: odoo/enterprise#122133
This update simplifies invoices for regular users by hiding technical e-reporting details. Relevant e-reporting information is now logged in the invoice chatter, providing easy access for support and debugging, without cluttering standard invoices. Additionally, address validation errors for B2C invoices are no longer reported.
Original PR description
E-reporting technical fields were displayed directly on invoices, adding noise for regular invoicing users. Hide the e-reporting status columns and technical block from the standard invoice views, while keeping them available for debugging. Log the relevant e-reporting flow, status and blocking errors in the invoice chatter instead, with a link to the related flow. Also avoid reporting address validation errors on B2C invoices, as they are not required for Flux 10 e-reporting. Task-6273226 Forward-Port-Of: odoo/odoo#268499
Resolved issues and error corrections
Sales commission plans now prevent adding a salesperson whose start date falls after the plan's end date. This helps avoid invalid commission setup and reduces downstream errors in commission tracking.
Original PR description
Version: 18.0 Steps to reproduce: - open sale commission plans and create a new plan with an effective period - go to the salesperson tab and add a salesperson - set the salesperson from date after the plan end date issue: salesperson period start date was accepted even if it was set after the plan end date fix: added validation to raise an error when the salesperson start date falls outside the plan effective period task id: 6241188 Forward-Port-Of: odoo/enterprise#118289
This fix prevents an internal payment test from running in a setup where its assumptions do not apply. It helps keep automated validation reliable without changing customer-facing payment behavior.
Original PR description
`test_payment_state_after_invoice_edition_without_journal_entry` test fails when `accountant` module is not installed. The test is specific to a case where there is no journal entry linked to a payment. However, when `accountant` module is not installed, a journal entry is always linked to the payment. runbot-941263
A test for duplicating field service subtasks was updated so it no longer depends on an internal ordering that can vary. This helps keep automated checks stable and reduces false failures during development and releases.
Original PR description
Steps to Reproduce --- 1. Install industry_fsm_report. 2. Run the test test_subtasks_worksheet_template_id_duplicate Issue --- The test fails because it relies on positional index assertions (child_ids[0] and child_ids[1]). Since child_ids is now returned with the ordering (id desc), the subtasks are processed in a different order during copy, causing the assertions to no longer match the expected records. Fix --- Sort both the original and duplicated subtask recordsets by name. task-5966684
This update fixes an error that occurred when clearing the date field in the WIP Accounting Entry wizard. Previously, the wizard would crash. Now, users can temporarily empty the date field while editing the wizard without causing an error, ensuring smoother workflow.
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 Forward-Port-Of: odoo/odoo#273002
This update resolves a recurring issue that caused the HTML editor to sometimes fail during testing. The fix addresses a timing problem related to how the browser handles updates, ensuring the editor's toolbar functions reliably. This improves the overall stability and user experience of the HTML editor.
Original PR description
### Description of the issue/feature this PR addresses: - Resolve non-deterministic failures in the 'toolbar should not open between double and triple click' Hoot test. - Because browser-level selectionchange events are dispatched asynchronously in the event loop, asserting on the presence of `.o-we-toolbar` in the DOM leads to timing race conditions. ### Solution: - Resolves the flakiness by introducing a wrapper method `triggerDebouncedUpdateToolbar` in `ToolbarPlugin` and refactoring the test to track method call sequences instead of asserting on DOM elements. This verifies the scheduled debounced updates in a deterministic sequence. task: https://runbot.odoo.com/odoo/error/243145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273648 Forward-Port-Of: odoo/odoo#273303
This update resolves an issue where the live chat system would crash when a chatbot attempted to forward a conversation to an operator, and no operators were configured for that channel. The fix prevents the system from attempting to process an empty operator list, eliminating the error and ensuring smooth chatbot operation.
Original PR description
When a live chat channel has no operators configured and the chatbot script ends with a Forward to operator step, triggering that step causes a traceback. Steps to reproduce the error: - Install…
When a live chat channel has no operators configured and the chatbot script ends with a Forward to operator step, triggering that step causes a traceback. Steps to reproduce the error: - Install ``im_livechat`` module with demo data - Go to Live Chat > Configuration > Chatbots > Create a new chatbot > Add script > Step Type: Question > Set answers > Save > Add script > Step Type: Forward to operator > Only If: Set one of the above answers > Save - Go to Live chat > Channel > Click the configure channel on YourWebsite.com > Remove the operators > Save - Go to the chatbot > test > select the configured answer Traceback: ```py StopIteration ``` https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/im_livechat/controllers/chatbot.py#L65-L70 When the chatbot script reaches a Forward to operator step while no operator is configured in the live chat channel, no chatbot message is created. As a result, the generator iterates over an empty iterator, and the ``next()`` call raises a ``StopIteration`` exception, causing a traceback during the conversation. sentry-7435424405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261726
This update clarifies the descriptions for both User and Administrator groups within the Project module. The changes improve clarity regarding user access to projects and reporting capabilities, ensuring accurate understanding of permissions.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update resolves an issue where invoices were displaying an incorrect final amount due due to a misinterpretation of loyalty program discounts. The fix ensures that tax calculations are accurate, particularly when loyalty discounts are applied, preventing a small discrepancy in the invoice total. This improves the reliability of the POS order process.
Original PR description
When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused…
When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused them to be grouped separately. This caused a discrepency between the tax amount computed in the frontend and the one computed in the backend. Steps to reproduce: ------------------- * Change the rounding method to globally * Create a 21% tax not included in price * Create a product with a price of 76.01 and the tax created above * Create a loyalty program with a 10% discount * Create a POS order with the product above and apply the loyalty program * Validate the order and generate the invoice > Observation: The invoice states that 0.01$ is still due Why the fix: ------------ In `round_tax_details_tax_amounts`, we try to detect any delta with the expeced tax amount. To do that we group the base lines based on a grouping key. The grouping key `is_refund` was incorrectly set to `true` for reward lines, which caused them to not be grouped. The delta was then not detected and tax amounts were not adjusted. We now make sure not to consider reward lines as refund. opw-6052112 Forward-Port-Of: odoo/odoo#273397 Forward-Port-Of: odoo/odoo#271577
This update corrects a visual issue where the background color of the account type selection dropdown remained in light mode when dark mode was enabled. The change ensures the dropdown's background color matches the overall dark mode theme, improving the user experience and visual consistency. This fix was implemented to maintain a polished and professional appearance across all Odoo environments.
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#274098 Forward-Port-Of: odoo/odoo#271352
This update fixes an issue where template tasks were incorrectly counted in task views and notebooks. The change ensures that task counts accurately reflect only real subtasks, improving the clarity and usability of project management within the Odoo system. This ensures accurate reporting and task management.
Original PR description
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab,…
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task type into account. Current Behaviour --- - For a normal parent task, both the normal sub-task and the template sub-task are counted and shown in the opened subtask view and notebook. - For a template parent task, the same filtering is applied, even though template subtasks should remain accessible in that context. Expected Behaviour --- - For a normal parent task, only real sub-tasks should be counted and shown in the subtask view and notebook, and on the project kanban card. - For a template parent task, template subtasks should remain available in the subtask view and notebook according to the parent template context. - In the project kanban card, tasks must not be counted when their parent task is a template, even if the child task itself is not a template. Fix --- - Apply template-aware filtering to subtask counting,project kanban task count and subtask view behavior, depending on whether the parent task is a normal task or a template task. task-5966684
This update corrects a previous error that triggered a user error message when generating invoices for Co-Contractant tax situations. The fix ensures that a note is only added to the invoice when the Co-Contractant tax amount is zero, aligning with standard fiscal practices. This improves invoice accuracy and user experience.
Original PR description
We were raising a UserError because we were putting the note even if the tax amount was different from 0. But in fact, it can be normal to have 0% cocontractant tax and normal rate at the same time on an invoice, which would have the fiscal position Co-Contractant. So remove these UserError, but only apply the note when the tax amount is 0 opw-6302806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274117 Forward-Port-Of: odoo/odoo#268899