Daily updates from Odoo
Tuesday, December 2, 2025
29 changes · saas-18.3
New functionality added to Odoo
This update adds support for payroll calculations in eight additional US states: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon, and North Carolina. This expansion improves the accuracy and functionality of the US HR payroll module for businesses operating in these regions.
Original PR description
…, NC) With this, we add support for 8 more states in the US payroll: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon and North Carolina. Task: 5247501 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#238056 Forward-Port-Of: odoo/odoo#237908
This update expands Odoo's US payroll functionality to include support for Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon, and North Carolina. This enhancement ensures accurate payroll calculations and compliance for businesses operating in these additional states.
Original PR description
With this, we add support for 8 more states in the US payroll: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon and North Carolina. Task: 5247501 Forward-Port-Of: odoo/enterprise#100927 Forward-Port-Of: odoo/enterprise#99278
Enhancements to existing features
This update ensures Odoo correctly handles German B2G invoices in the XRechnung format. It adds a mandatory 'Leitweg-ID' to the invoice XML, directing invoices to the appropriate public entity as required by German regulations. This improves compliance and accuracy for transactions within Germany.
Original PR description
*= l10n_account_edi_ubl_cii_tests For B2G transactions in Germany, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. Adding this Leitweg-ID for the UBL syntax. task-5194484 Description of the issue/feature this PR addresses: For electronic invoicing in Germany, for B2G transactions, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. We want to add this identifier for the XRechnung format. Current behavior before PR: The Leitweg-ID is not present in the UBL xml format. Desired behavior after PR is merged: The Leitweg-ID is added in the header of the invoice in the cbc:BuyerReference tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236333
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new rule has been added specifically for Belgium, leveraging the VAT number to streamline Peppol identifier identification through the company registry.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#233160
Resolved issues and error corrections
This update resolves an issue where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. The fix ensures that input values are correctly saved and reflected, providing a more reliable experience for users. This improves data accuracy and reduces potential data loss.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069 Forward-Port-Of: odoo/enterprise#96431
This update corrects a bug where administrators without HR permissions could trigger an error when attempting to create a new employee. The fix hides the 'Create Employee' button for users lacking the necessary HR rights, ensuring a smoother user experience and preventing unexpected errors.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Make sure Marc Demo is an Administrator but has no Employees (HR) access rights. - Log in as Marc Demo. - Go to Settings → Users → Create a new user. - Enter a name and email, then Save. - You’ll see the "Create Employee" button it appears even though the user has no HR rights. - Click it → an Access Error occurs. **Isuue:** - The "Create Employee" button is visible for users who don’t have HR permissions, causing an access error when clicked. **Solution:** - Hide the "Create Employee" button for users without HR access by adding the correct group restriction. task-5212464 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#235258
This update fixes an issue where Colombian e-invoices were failing validation due to incorrect XML formatting for the 'INC Bolsas' plastic bags tax. The changes add specific logic to generate the required XML structure, ensuring compliance with DIAN regulations and successful invoice submission.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926 Forward-Port-Of: odoo/enterprise#95311
This update enhances the reliability of payment processing for German POS systems by automatically retrying failed transactions (5xx errors) and ensuring tills remain operational even when the payment server is temporarily unavailable. This prevents disruptions to sales and improves the overall user experience.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#100625 Forward-Port-Of: odoo/enterprise#93694
A recent update to the l10n_ar module's demo data caused installation issues with Python 3.10 due to a formatting error. This fix corrects the code to ensure compatibility with the newer Python version, allowing the demo data to install correctly and providing a functional demonstration of the module.
Original PR description
**Steps to reproduce:**
- Use Python 3.10
- Install l10n_ar
**Issue:**
The installation fails with a SyntaxError.
**Cause:**
Some demo data use the following format for the taxes definition:
`ref(f'account.{ref('base.company_ri')}_ri_tax_vat_0_compras')`
However, in python 3.10, a quote cannot be used inside f''.
opw-5376152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238186This update fixes an issue where the ‘Late Activities’ and ‘Today’s Activities’ counters on the Recruitment dashboard didn't update correctly after an activity was marked as done. The fix ensures that inactive activities are no longer counted, leading to more accurate activity tracking for recruiters. This improves the overall reliability of the Recruitment process.
Original PR description
On the Recruitment dashboard (Jobs kanban), the counters for “Late Activities” and “Today’s Activities” may not decrease after an activity is marked as done, even though completed activities no longer appear in the applicant list. Root cause: `_compute_activities` aggregates counts from `mail_activity` using the deadline and job filters but does not exclude non-running (inactive/archived) activities. If an activity is not unlinked and becomes inactive (`active = FALSE`), it still matches `date_deadline <= today` and is counted. Steps to reproduce: 1. Open Recruitment 2. Pick any job and schedule an activity with Due date is Today (also try Yesterday for “Late”). 3. Mark the activity as Done. the number of activities today or late will not decrease opw-5123947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor issue where the PEPPOL data neutralization script didn't function correctly when a required key was missing. The fix ensures the script now properly inserts the key, guaranteeing consistent PEPPOL data processing. This improves the reliability of our PEPPOL integration.
Original PR description
There can be some siutations where you can not have the key account_peppol.edi.mode while having a connection. But the neutralize only updates and so, if the key is not present, it does nothing. So change it to insert the key if no present --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238184
This update resolves a technical issue that prevented the printed receipt tour from functioning correctly after installing the `l10n_it_pos` or `l10n_se_pos` modules. The fix corrects a programming error that caused a runtime error, ensuring the receipt tour works as expected for users.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing `l10n_it_pos` or `l10n_se_pos`. runbot-233248 Forward-Port-Of: odoo/enterprise#97355
This update fixes several issues within the o_spreadsheet component, ensuring its smooth operation and stability. The changes include improvements to pivot tables, chart loading, and data synchronization, ultimately enhancing the spreadsheet functionality for users. This is a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a205f911b [REL] 18.3.28 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a205f911b [REL] 18.3.28 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4777025ff [FIX] pivot: Ensure computed measure range adaptation [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/d52b5908e [FIX] commands: remove duplicate in invalidateEvaluationCommands [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/d146422ad [FIX] Charts: Ensure Chart js extension are loaded on chart creation [Task: 5214007](https://www.odoo.com/odoo/2328/tasks/5214007) https://github.com/odoo/o-spreadsheet/commit/eb5f59104 [FIX] composer: keep edition mode inactive on cursor selection change [Task: 5354541](https://www.odoo.com/odoo/2328/tasks/5354541) https://github.com/odoo/o-spreadsheet/commit/8952d1927 [FIX] BottomBarSheet: sheet name should update on foreign changes [Task: 5016252](https://www.odoo.com/odoo/2328/tasks/5016252) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where test emails using 'view_online' would fail if the associated mailing contact was deleted. The fix ensures the system retrieves the first available mailing contact ID, preventing the 'record not found' error. This improves the reliability of test email campaigns.
Original PR description
In the email marketing, when you add "view_online" and dynamic placeholder "object.name", and try doing a test email, it creates a url token for the "view online" with the res_id as the user's id which grabs the record from the mailing_contact with that res_id. So, in case the mailing_contact with the res_id is deleted, the "view_online" gives you error saying record with id "res_id" cannot be find. Our fix is to search the mailing_contact and grab the id of the first record. This fix updates the code from this commit: [8a9981e](https://github.com/odoo/odoo/commit/8a9981e78a438ceb53a4fdc0445ebed2170c6624) opw-5049654 Forward-Port-Of: odoo/odoo#232440
This update resolves a critical error that prevented the generation of payroll export files. The fix corrects a naming mismatch in the code, ensuring the correct Prisma data is exported. A new test suite has been added to guarantee the accuracy and reliability of the export process.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#96743
This update fixes a technical issue related to how error messages are displayed in stock order management. Previously, the system was generating excessive activity, but this change ensures that error messages are handled correctly and efficiently. This improves performance and prevents unnecessary system load.
Original PR description
From saas-18.2 and later, html fields has been changed the old behaviour.
Ex.
```python
model.create({'note': 'test'}) -> <p>test</p>
```
Old behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 1
```
New behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 0
```
To follow the new behaviour and not generate infinite activities, we need to add html elements to the error message.
Additional, we improved the performance (better to count and limit vs see all the whole table).
OPW-5266061
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#237977This update resolves an issue where duplicating an approver on an approval request would cause a system error. The fix prevents the same user from being linked to multiple approvers, eliminating the traceback and ensuring approval requests can be properly opened. This improves stability and prevents disruptions to the approval workflow.
Original PR description
When User duplicates the approver for any approval request and tries to open that approval request, A traceback will appear. Steps to reproduce the error: - Activate the developer mode - Go to Approvals > Create a new approval request > add any approver > Save - Click on the ``View`` button in the approver line - Now, In the Form view > Actions > Duplicate - Go back to that approval request through breadcrumbs Traceback: ``` ValueError: Expected singleton: approval.approver(1, 3) ``` https://github.com/odoo/enterprise/blob/83b6c0e1c052b08bd23c5e009773b5a3148ddeec/approvals/models/approval_request.py#L270 When the customer duplicates the approver, ``user_id`` will be also duplicated. So, Now Same User is linked with multiple approver. So, It will lead to the above traceback. sentry-6642840799 Forward-Port-Of: odoo/enterprise#100979 Forward-Port-Of: odoo/enterprise#87164
This update fixes an error that occurred when creating new product templates without a pre-existing product. It ensured the product's launch date was correctly calculated, preventing a comparison error that could disrupt product information. This improves data accuracy and stability for new product listings.
Original PR description
If _compute_write_date is launched when creating a product.product without starting from an existing product.template, the compute may be launched before the product.template is created, hence record.product_tmpl_id.write_date is False, and comparing datetime and bool leads to an error. This completes the fix proposed https://github.com/odoo/odoo/pull/138177 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237756 Forward-Port-Of: odoo/odoo#237523
This update resolves a problem where users couldn't correctly test the selection of work order lots within the shopfloor view. The fix ensures that the necessary user group (`stock.group_production_lot`) is included in the test environment, allowing for accurate testing and proper functionality. This prevents potential errors when users are selecting lots for production work orders.
Original PR description
The user need to be part of the group `stock.group_production_lot` to see the `lot_id` in the view used to select a quant in the shopfloor. https://github.com/odoo/odoo/blob/0e50df1ea86b3c9584f407bdbc39b4e308b9c8d8/addons/stock/views/stock_quant_views.xml#L164-L166
This update ensures that online payments are immediately processed, regardless of whether the user views a confirmation page. Previously, delays caused confusion for customers and cashiers. Now, the system automatically triggers order processing after receiving payment confirmation, leading to a smoother customer experience.
Original PR description
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a…
..., pos_online_payment_self_order Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page, which triggered the payment transaction post-processing. However, in some cases, the user never reaches this page. For example: the user sees that the payment succeeded in their banking app and closes the tab before being redirected to the confirmation page. To still process the orders, a cron runs every 10 minutes to post-process transactions that were not processed yet. However, for POS self-orders this is not ideal: we need the order to be processed as soon as possible since we are in direct contact with the user. A situation where the customer insists their payment went through but the cashier sees no updated order creates unnecessary confusion. --- To fix this, we now trigger the cron directly after receiving the callback from the payment provider. This ensures that the transaction (and therefore the order) is always post-processed immediately and kept up-to-date, even if the user never reaches the confirmation page.
This update fixes a problem where online payment confirmations weren't always triggering order delivery to the kitchen (PDIS). Now, a scheduled process automatically sends self-order and kiosk payment orders to the kitchen regardless of the user's confirmation page interaction, improving order accuracy and reducing potential confusion.
Original PR description
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the…
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS). However, in some cases, the user never reaches this page. For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens. For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff. Relying solely on the confirmation page was therefore unreliable. --- To fix this, we now leverage the cron that post-processes payment transactions: we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen. This ensures that orders reach the PDIS even when the user never lands on the confirmation page.
This update fixes a bug where reverse charge tax amounts were incorrectly recorded on invoices created with down payments from sales orders. The change ensures that reverse charge tax is now correctly applied to the credit side, aligning with accounting regulations. This improves the accuracy of financial reporting.
Original PR description
When creating an invoice with down payment from a sales order, the reverse charge tax amount goes into the debit side. Make sure the reverse charge tax amount goes into the credit side. opw-5172402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where error messages weren't being properly handled during automated retry attempts, leading to build failures. The change ensures that tracebacks and other error messages are now correctly processed, resolving a bug and preventing disruptions to the system. It also addresses a related OSError that could occur during websocket handling.
Original PR description
The auto-retry is supposed to catch error logs as well as tracebacks. In some cases a traceback is logged as a message, and not as a logger arg, bypassing the replace already in place. This pr simply replaces the traceback string in the message as well. Build error [234619](https://runbot.odoo.com/odoo/runbot.build.error/234619) Also fixes OSError while handling request paused Build error [229906](https://runbot.odoo.com/odoo/runbot.build.error/229906) Forward-Port-Of: odoo/odoo#238133
This update replaces the specific "Uruware" name in the Odoo settings with a generic "UCFE Provider" label for the electronic invoicing provider. This ensures customers contact Odoo support directly, streamlining assistance and maintaining a consistent configuration for Uruguayan users. The core functionality remains unchanged.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539 Forward-Port-Of: odoo/enterprise#101027 Forward-Port-Of: odoo/enterprise#99065
This update fixes an issue where Point of Sale orders containing variant kits didn't correctly generate the necessary picking lists. Previously, only one variant's specific components were included. Now, the system accurately creates picking lists for all variant components within a kit, ensuring complete order fulfillment.
Original PR description
When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2…
When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2 kits with different variants. Steps to reproduce: ------------------- * Create a product P * For product P, create an attribute with type "No variant" and values V1 and V2 * Create a BoM Kit for product P, with 3 components C1 C2 and C3 - C2 applies only for variant V1 - C3 applies only for variant V2 * Create a POS order with 2 lines of product P: - 1 with variant V1 - 1 with variant V2 * Validate the order and check the created picking > Observation: Only C1 and C2 are in the picking, C3 is missing Why the fix: ------------ When creating the picking, the code was grouping the order lines by product only, and not by product variant. Therefore, the 2 lines would be grouped together, and only one of the variant-specific components would be taken into account. opw-5051289 Forward-Port-Of: odoo/odoo#237796 Forward-Port-Of: odoo/odoo#235528
This update resolves an issue where pressing the TAB key while adding notes to sale order lines would clear and remove the entered text instead of saving it. The fix ensures that users can now correctly add and save notes within the sale order line interface, improving data accuracy and usability.
Original PR description
## Versions 18.0 > saas-18.4 Fixed in 19.0 thanks to bc6592a8514d6557037868a0f42265070fa02263 introducing the `parseLabel` method: https://github.com/odoo-dev/odoo/blob/19e03df5d9546d3948c2a184a6f26db7ba3aec71/addons/account/static/src/components/product_label_section_and_note_field/product_label_section_and_note_field.js#L47-L51 ## Issue When adding a section or a note line in the sale order lines list view, pressing TAB key caused the line to be cleared and removed instead of being saved. ## Steps to reproduce - Open an invoice or create one for any customer: - Click either on "Add a section" or "Add a note"; - Write something down; - Press the TAB key. ## Fix Handle the field with the appropriate `useInputField` hook. opw-4967733 Forward-Port-Of: odoo/odoo#237222 Forward-Port-Of: odoo/odoo#230644
This update optimizes how Odoo calculates mobility budgets for Belgian employees. By switching to a more efficient search method, the calculation process is now significantly faster, particularly for larger datasets. This improves the overall performance and responsiveness of the HR module.
Original PR description
- optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389 Forward-Port-Of: odoo/enterprise#99505
This update fixes a technical issue that prevented completion notifications from being translated into different languages within the Odoo Enterprise system. The fix ensures all notification messages are properly localized, improving the user experience for international customers. This change enhances the system's adaptability and supports global operations.
Original PR description
The `_t()` was put around the wrong thing, making the strings never translatable. Followup to: 4403621
This update resolves an issue where administrators could still access documents from companies that had been archived within the Documents app. The fix ensures that archived companies are properly excluded from search results for regular users, maintaining data security and preventing unauthorized access. This improves the overall reliability of the Documents app.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040 Forward-Port-Of: odoo/enterprise#100133