Friday, February 20, 2026
54 changes · saas-19.1
Resolved issues and error corrections
This update resolves a connection issue that occurred when Odoo was configured to use a replica database. The change ensures Odoo automatically uses the primary database port when a replica port isn't specified, preventing errors and improving database connection stability. This enhances the overall reliability of the Odoo system.
Original PR description
Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.
The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.
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#249291This update resolves an issue where the AI translation feature in the website builder would fail due to a 10-second timeout. The fix removes this timeout restriction, allowing translations to complete successfully even with large amounts of untranslated text. This improves the user experience for translating website content.
Original PR description
Scenario: - have lot of untranslated text in a page - in a secondary language, open translation editor - click on "Translate to [current language]" in side panel Result: the translation fails completely or partially, and there is a notification saying "A technical issue occurred in the builder, you should save or discard your changes.". Reason: since 6df83abb35c95ab42e55d9a08cf6c411efa64b3e website builder action have a default timeout of 10 seconds to prevent deadlocks. But the /html_editor/generate_text can easily take more than 10 secondes depending on latency and quantity of text to translate. Fix: prevent the timeout when using the AI translation feature. opw-5892402 Forward-Port-Of: odoo/odoo#249464
This update ensures that expense accounts are linked to the correct company when using products. Previously, expenses created for one company would incorrectly use accounts from a different company. This fix resolves a potential issue with inaccurate financial reporting and improves data consistency.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717 Forward-Port-Of: odoo/odoo#249194 Forward-Port-Of: odoo/odoo#209144
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated to reflect a recent change in how timesheet validation is handled within the Odoo system. This ensures the email reminders function correctly.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update corrects a bug where PDFs attached to bills created via email aliases weren't correctly linked. The fix clears a key field when an attachment is removed, preventing misassignment of attachments between bills and XML documents. This ensures consistent attachment functionality regardless of the bill creation method.
Original PR description
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to…
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to create a bill via email aliases, the PDF is not set as the bill’s main attachment. Root cause: 1. When an email is received, it's first posted as a message on the bill chatter 2. Posting the email sets its XML as the main attachment of the bill 3. _fix_attachments_on_record from account.document.import.mixin then removes res_id and res_model fields from the XML 4. The PDF is then attached as the main attachment of the bill 5. In documents_account module, when the PDF is set as the main attachment, it mistakenly assigns it as an attachment to the XML document because the XML was assigned as the bill main attachment, resulting in the bill having no attachment actually linked to it. Solution: This commit fixes this issue by clearing the field message_main_attachment_id whenever the attachment in it gets unattached in _fix_attachment_on_record. task-5900088 Forward-Port-Of: odoo/odoo#246991
This update prepares the l10n_eu_iot_scale_cert module for compatibility with Odoo 19.0. It simplifies communication with IoT devices and removes outdated features related to manual quantity adjustments, ensuring accurate certification processes.
Original PR description
This PR adapts the l10n_eu_iot_scale_cert module for the certification in v19.0 1) It adapts the communication with the iot box to use the new iot_http_service 2) It removes the possibility to manually change the quantity on a weighed product 3) It removes the possibility to set a negative tare Related PR in v18: https://github.com/odoo/enterprise/pull/107103 task-5926814 Forward-Port-Of: odoo/enterprise#107123
This update ensures seamless communication between Odoo's IoT boxes and databases, specifically addressing a change in data format between versions 18.0 and 19.1. The update adjusts the IoT box to send both expected data values, resolving compatibility issues and maintaining reliable data flow.
Original PR description
This PR adds the scale commands compatibility for the iot box images in >= saas-19.1 with the dbs in v18.0 and less In v18.0 we read 'value' key sent by the iot box but the iot box doesn't send it anymore in 19.1 This PR makes the iot box send both 'result' as exepcted in v19 and 'value' expected in v18 Enterprise PR: https://github.com/odoo/enterprise/pull/107641
A recent update caused a crash when users tried to undo a duplicated list within the spreadsheet feature. This fix ensures that users can now correctly undo actions, including list duplication, without experiencing unexpected errors. This improves the stability and usability of the spreadsheet functionality.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This update resolves an issue where upgrades were failing due to delayed constraint definitions. Specifically, when modules loaded in a different order, outdated constraint definitions were causing errors. This patch ensures the latest definition is always applied, improving the stability and reliability of Odoo upgrades.
Original PR description
Current issue: Module A fails to add constraint X with definition D1 -> (X,D1) is delayed Module B loaded after A, overrides constraint X to D2 and also fails to add the constraint -> still (X,D1) are in the delayed queue, instead of (X,D2) In this patch we ensure the delayed constraint gets the latest definition (D2) This issue affects upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249495
This update resolves a technical issue that could cause errors when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and preventing unexpected errors. This improves stability and usability.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update fixes issues with how custom snippets are displayed in the website editor's preview. Specifically, it ensures consistent preview heights for carousel snippets and correctly shows zoom effects for parallax snippets, while also ensuring custom snippet labels are displayed. These changes improve the user experience when creating and managing website content.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present** Forward-Port-Of: odoo/odoo#248929 Forward-Port-Of: odoo/odoo#244295
This update fixes an issue where the website filters disappeared when using the 'off-screen menu' style. The change ensures the filters button remains visible when no sort or pricelist options are selected, providing a consistent and user-friendly experience for browsing products.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858
This update enables users to remove orderlines when using the LNE certified scale module in Point of Sale (PoS). Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring data accuracy for scale-based transactions. This resolves a previous limitation and improves the usability of the certified scale functionality.
Original PR description
This PR allows the user to delete PoS orderline when using LNE certified scale module while still forbidding to manually set quantity to anything other than 0 Forward-Port-Of: odoo/enterprise#107413
This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of when it was created or modified. Previously, this information was unreliable due to a manual process, now it's automatically calculated and updated whenever a contract version changes, improving payroll accuracy and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#102198This update corrects a technical issue within Odoo's testing framework related to how webjson responses are processed. Previously, a test was failing due to an unexpected data type being returned. This fix ensures that tests accurately reflect the expected behavior of the webjson functionality, improving overall test stability.
Original PR description
The return value of the patched methods was a MagicMock and not a recordset, and make_json_response was doing funny stuff with that returned MagicMock 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#249496
This update prevents discounts applied to recurring subscription lines from being removed when an upsell is added to the order. Previously, confirming an upsell would reset the discount, leading to incorrect pricing. This change ensures accurate discount calculations for subscription orders with upsells, improving order accuracy and customer satisfaction.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750
This update adds a warning message to the invoice batch wizard when the automated invoice sending cron job is disabled. This ensures users are alerted if their invoices won't be sent, preventing potential delays and improving invoice processing transparency. It addresses feedback from SBR to enhance user experience.
Original PR description
When the Cron responsible of sending the invoices asynchronously is disabled, the user has no clear indication that his invoices won't be sent as they should. Let's add a warning in the batch wizard that notify the user something is wrong. task-none (feedback from SBR) Message when no rights to update cron: <img width="990" height="328" alt="image" src="https://github.com/user-attachments/assets/1100ef6f-d047-49f2-bd8f-c8ef9fd543d8" /> Message when admin: <img width="999" height="308" alt="image" src="https://github.com/user-attachments/assets/28e90295-d225-4785-82a9-65be3ce79621" /> Forward-Port-Of: odoo/odoo#249270 Forward-Port-Of: odoo/odoo#248994
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when creating accounting records. The fix ensures invoices are processed with the correct company details, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249409 Forward-Port-Of: odoo/odoo#249059
This update resolves a bug that caused forum posts to fail to create when the Odoo system was in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable user experience.
Original PR description
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249477 Forward-Port-Of: odoo/odoo#244063
This update resolves a technical issue that prevented emails from being sent correctly when processing multiple equity transactions. The fix corrects a configuration error within the email template, ensuring accurate record matching and preventing errors during email generation. This improves the reliability of equity transaction notifications.
Original PR description
## Issue Before This Commit A missing record error occurred during email generation when the number of `equity.transaction` records exceeded the `res.partner` records. ## Cause of the Issue The issue was caused by an incorrect `model_id` configuration in the `equity_shareholder_email_template`. This created a mismatch between the template model and the record context passed to the mail compose wizard, leading to a missing record error during template rendering. ## With This Commit The template `model_id` has been corrected `equity.transaction`. This ensures that the mail compose wizard receives the correct model context and prevents missing record errors during email generation. Steps to reproduce : [Video](https://drive.google.com/file/d/19WXbjmYPKh0IjQHcEGU4FdUbGSF4GGlx/view?usp=drive_link) opw-5899070 Forward-Port-Of: odoo/enterprise#107891
This update resolves an issue where changing a partner in Odoo would erase the previously set default payment term for invoices. Now, the default payment term will remain consistent, regardless of the partner being used, ensuring a smoother and more reliable invoicing process. This prevents frustration and maintains data integrity.
Original PR description
When you want to set a default payment term for an invoice, it will be there when you create the invoice. But then, when you change the partner, even if there is no default payment term defined on there, it will empty it, so setting a default does not work. This can even be annoying if you set the payment term first and then the partner. In odoo/odoo#112360 this condition was added for perf issues. opw-5387239 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#242041
This update fixes an issue where the working time assigned to tasks wasn't accurately calculated when switching between companies with and without public holidays. The fix ensures that working time is correctly computed based on the last stage change and considers company-specific holiday impacts.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#246994
This update corrects a bug where high-priority applicants weren't appearing at the top of the applicant list in the Recruitment module. The fix resolves a technical issue with how applicant priority was being ordered, ensuring that the most important applications are now displayed first.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any…
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any application Very High Priority (3 star) 5. Refresh the page Observation: ---------------------------------------- Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage. Issue: ---------------------------------------- The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41 Solution: ---------------------------------------- Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first opw-5893371 Forward-Port-Of: odoo/odoo#247779
This update fixes an issue where changes made to email marketing records within the form editor were lost when switching between tabs. The fix ensures that the editor correctly saves changes when the focus is lost, improving the user experience and data integrity. This prevents data loss and ensures consistent email marketing campaigns.
Original PR description
Problem: While editing an email marketing record, switching tabs in the form view causes the last changes in the editor to be lost. Cause: The `blur` event on the iframe is not triggered when clicking outside of it. If the iframe is not fully ready when listeners are attached, the required events are not properly registered, so the latest changes are not saved before switching tabs. Solution: Attach the `blur` listener only once the iframe is fully loaded, ensuring that changes are correctly detected and saved when focus is lost. Steps to reproduce: - Create a new email marketing record. - Add a text snippet. - Change the text and save. - Modify the text again. - Switch to another tab in the form view, then return to the "Mail body" tab. - Observe that the last changes are lost. opw-5921800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248974
This update resolves an issue where clicking on certain activity types (like 'Eat cookies') in the calendar view would cause a technical error (traceback). The fix ensures that these activities can now be properly viewed, improving the user experience and preventing disruptions.
Original PR description
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click…
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click “View” in the popover. => Traceback Reason ====== The commit [1] allow activities without a linked model and from commit [2] such activities can be opened in the activity form view. In the calendar view, the action is retrieved from the model and executed using `doAction`. Since the action does not define `views`, and the `doAction` depends on `action['views']`, an error occurs when the action service attempts to copy it. After this commit ================== This commit fixes the issue by modifying the action returned from `action_open_document` for non-linked models to include `views`, similar structure used when a model is present. [1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69 [2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d Task-5857887 Forward-Port-Of: odoo/odoo#246442