Friday, February 27, 2026
20 changes · saas-18.4
Resolved issues and error corrections
The booth booking flow now tells returning contacts they can either sign in or create an account when their email is already recognized. This avoids confusion for customers who exist in the system but do not yet have portal access, making the booking path clearer.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This fix prevents certain internal settings from being incorrectly applied in a way that created excessive logging. It helps keep automated tests faster and more reliable, reducing the chance of false failures during development and release preparation.
Original PR description
Followup / fixup to #249005, as these can / do cause trouble due to overlogging (mostly the chart_template one). Forward-Port-Of: odoo/odoo#250575
Duplicating a project task now skips subtasks that were archived. This prevents old or inactive work items from reappearing in copied tasks, keeping project records cleaner and reducing manual cleanup.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250901 Forward-Port-Of: odoo/odoo#248167
This update backports fixes for Odoo's internal web testing tools. It improves how test results and file responses are handled, helping developers identify issues more accurately and maintain product quality.
Original PR description
### [FIX] web: Hoot - backport fixes This commit backports the following fixes that have been applied in further versions: - add correct mime type to XHR blob responses [1]; - fix missing diff from failed test results [2]; - wrap 'raw' value option in a dictionnary to limit unintended use, use 'raw' as a default for text-based matchers [3]. [1] 9156bf1 [2] 2216a0b [3] 3080362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250929
This update fixes a typing-related error in the Sales combo configurator. It helps prevent interruptions when users configure bundled or combo sale products, improving reliability with minimal business impact.
Original PR description
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 Forward-Port-Of: odoo/odoo#249973
Time off types now correctly include still-valid employee allocations that began in the previous year when showing the allocation count. This prevents mismatches between the number shown on the time off type page and the allocations list users see after clicking it.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250378 Forward-Port-Of: odoo/odoo#248482
This fix prevents crashes when editing tables in Studio by ensuring the editor has the overlay settings it expects. It also improves table menu placement when content is edited inside an embedded frame, making table editing more reliable for users.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. ENT PR: https://github.com/odoo/enterprise/pull/108724 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/odoo#250889 Forward-Port-Of: odoo/odoo#250645
This fix ensures very small spacing or sizing values in the HTML builder are handled correctly instead of being mistaken for zero. It helps preserve intended page layouts and reduces unexpected visual changes when editing website content.
Original PR description
**Description:**
Replace parseInt() with parseFloat() in areCssValuesEqual() zero check. parseInt("0.1rem") incorrectly returns 0, causing fractional values like 0.1rem to be treated as zero and skip unit conversion.
opw-5412414Fixes an issue where restarting a live chat bot after reloading the page could show duplicate question prompts. This helps keep customer support conversations clear and prevents confusing repeated bot steps.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 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 Forward-Port-Of: odoo/odoo#250623
Purchase receipt descriptions now avoid showing the vendor product code or name twice. This keeps warehouse receipt forms cleaner and reduces confusion when matching received goods to purchase orders.
Original PR description
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order for this product with the right vendor and confirm it. Go to the delivery receipt, the vendor code and/or name are added twice in the description. Why is it happening ------------------ The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name. Solution ------------------ I propose to remove the code and the name from the vendor_reference variable if the original description already contains them. opw-5392855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users create replenishment orders using pack-based multiples, such as ordering in packs of six. Businesses can now use order-to-maximum replenishment rules without the process failing unexpectedly.
Original PR description
Backport of: https://github.com/odoo/odoo/commit/fe806166968d55a70f5bf335dcb3633e18d8ecc7 Steps to reproduce: - Create a storable product “P1”: - UoM: Unit and Pack of 6 - Purchase tab: add any vendor - Go to Replenishment and create a new rule: - Product: P1 - Min: 10 - Max: 100 - Replenishment Multiple: Pack of 6 - Select the line and click “Replenish” → “Order to Max” Issue: A traceback is raised: “TypeError: unsupported operand types in: uom.uom(2,) - 4.0” In `_get_qty_to_order`, we compute the quantity to order and then adjust it according to the replenishment multiple, but we try to Subtract the rounded remainder from the uom (which is a recordset) instead of the quantity (which is a float). opw-5947919
This update fixes issues in Odoo's automated test framework so tests are better isolated, report failures more clearly, and clean up after themselves. It helps reduce false test failures and makes future changes to web, mail, and editor features safer to validate.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250823 Forward-Port-Of: odoo/odoo#247137
This fix helps Belgian Peppol invoices use the correct company registration number format when generating electronic invoice data. It reduces invoice errors caused by entering a general company registry value instead of the expected BCE number.
Original PR description
We expect people to put BCE number in the company registry. But it is not enforced client-side, resulting in invoices in error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251168
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch clients, complying with local tax regulations and improving data consistency.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108575 Forward-Port-Of: odoo/enterprise#107949
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the intended work email. This prevents data inconsistencies and improves the accuracy of employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
This update resolves a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This improves the stability and accuracy of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update makes the Gantt chart's date selection more immediate, providing a smoother user experience. Previously, date changes required clicking 'Apply' to update the display. Now, selections update instantly, improving efficiency and reducing delays when adjusting the chart's timeframe.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671 Forward-Port-Of: odoo/enterprise#107380
This update fixes a potential issue with after departure payments to work. Now, if a previous payslip isn't selected, the system displays a clear error message to the user instead of a technical traceback. This ensures smoother and more accurate processing of these payments.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update resolves a technical problem where keydown events were incorrectly targeting the wrong element in the Hoot component. This fix ensures that Hoot functions reliably, improving the user experience. The change was made to stabilize the application and prevent unexpected behavior.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#108835 Forward-Port-Of: odoo/enterprise#107286