Monday, January 26, 2026
44 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue that occurred when upgrading Odoo with the l10n_id module installed. The migration script was incorrectly creating extra tax lines, leading to errors. This fix ensures a smoother and more reliable upgrade process for users with the l10n_id module.
Original PR description
Encountered an issue during upgrade from v16 with existing l10n_id installed on the DB. The script will try to force create the tax and create extra `repartition_line_ids` which is causing multiple "base" line to be added and trigger the `ValidationError`. Upgrade request: [3442445](https://upgrade.odoo.com/odoo/request/3442445) Upgrade task: [5314508]( https://www.odoo.com/odoo/70/tasks/5314508) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237897
This update resolves a technical issue causing errors when creating multiple companies with Sri Lanka settings. The problem stemmed from duplicate tax IDs in the accounting data, which incorrectly linked company records. This fix ensures accurate company setup and avoids data inconsistencies.
Original PR description
**STEP TO REPRODUCE** 1. create a company, and set country to Sri Lanka. 2. create a 2nd company, and do the same. 3. There is a company inconsistencies error. **CAUSE** There is 2 taxes defined in `account.tax-lk.csv` with `.` in their id. This messes up with the function `company_xmlid()`: we end up loading the `account.tax` record of the 1st company when saving the 2nd company. opw-5473952 Forward-Port-Of: odoo/odoo#245244
This update resolves an issue where the Point of Sale 'Settle Due' feature was blocked when ZATCA integration was enabled. The fix prevents the system from incorrectly forcing an invoice, allowing users to properly complete settlement payments without needing to create a new invoice for ZATCA.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244654 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user cancelled a payment attempt. By resetting the order flag, this prevents users from bypassing important business rules related to invoicing and reporting. This ensures accurate order processing and compliance.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104866 Forward-Port-Of: odoo/enterprise#98463
This update resolves an issue where applying text colors to lists in the HTML editor didn't correctly color the list markers. The fix ensures that text color classes remain on list items, resulting in consistent and accurate color matching for list markers. This improves the overall user experience when formatting lists.
Original PR description
### Steps to reproduce: - Create a list and type some text. - Press Ctrl + A and apply a text color from the toolbar. - Observe that the list marker is not colored. ### Description of the issue/feature this PR addresses: - `getFonts` looked for the closest element with a text color class, and this also matched `<li>` elements. When a `<li>` was selected, its text color class was removed and moved to a new <font> element created inside the `<li>`. - As a result, the color class was removed from the list item itself, which broke list marker coloring. ### Desired behavior after PR is merged: - Text color classes remain on list item, so list markers are colored correctly. task-5454639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243005
This update fixes a bug that prevented customers with names like "constructor" from being correctly processed in reporting. The change avoids issues with object initialization, ensuring customer names can be used without causing errors. This improves the reliability of customer reporting features.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691
Forward-Port-Of: odoo/odoo#245369
Forward-Port-Of: odoo/odoo#245206This update resolves a bug where self-order kiosks were printing blank tickets. The fix ensures that preparation printers without categories are not used for printing, aligning with the expected behavior of the self-order system. This prevents unnecessary printing and improves the kiosk experience.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245353 Forward-Port-Of: odoo/odoo#245193
This update fixes a test failure related to user assignments within work orders. The previous test setup caused a constraint error when multiple employees were assigned to the same user in succession. The fix involves using a different user during assignment to avoid this constraint, ensuring the work order functionality remains stable.
Original PR description
Before this commit, the test `test_allowed_employees_restriction` was failing because two different employees of the same company were assigned one after another to a same user. When the changes are commited, the constraint `_user_uniq` was triggered. Solution: use a different user instead of reassigning to the same one so that the constraint isn't triggered when setting another employee to the user. fixes odoo/enterprise#96931 runbot error 234537
A minor bug in the knowledge calendar tour was preventing it from completing correctly. This update fixes a reference error, ensuring the tour now successfully guides users through the property deletion process. This improves the overall user experience for the knowledge module.
Original PR description
In test_knowledge_calendar_command_tour there was a miss-referenced button towards the end. This caused the tour to fail because it didn't find the button to click. With this PR we correctly reference the button and allow the tour to finish. Runbot Error: 234898
This update fixes an issue where the FedEx rate selection process was failing when the requested currency didn't match the account's currency. The fix ensures the 'PREFERRED' rate type is consistently used, preventing errors and ensuring accurate shipping calculations. This improves the reliability of our FedEx integration.
Original PR description
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the…
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means `d['rateType'] == rating_result['actualRateType']` is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`. Solution ----- In the request we send, we hardcode `'rateRequestType': ['PREFERRED']` so we can look for a match using 'PREFERRED' as a prefix of `rateType`. The Fedex API lists all possible values of the enum `rateType` https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html <details> <summary>Enum values as per the API</summary> "enum": [ "INCENTIVE", "NEGOTIATED", "PAYOR_ACCOUNT_PACKAGE", "PAYOR_ACCOUNT_SHIPMENT", "PAYOR_CUSTOM_PACKAGE", "PAYOR_CUSTOM_SHIPMENT", "PAYOR_LIST_PACKAGE", "PAYOR_LIST_SHIPMENT", "PAYOR_RETAIL_PACKAGE", "PAYOR_RETAIL_SHIPMENT", "PREFERRED_ACCOUNT_PACKAGE", "PREFERRED_ACCOUNT_SHIPMENT", "PREFERRED_CUSTOM_PACKAGE", "PREFERRED_CUSTOM_SHIPMENT", "PREFERRED_INCENTIVE", "PREFERRED_LIST_PACKAGE", "PREFERRED_LIST_SHIPMENT", "PREFERRED_NEGOTIATED", "PREFERRED_RETAIL_PACKAGE", "PREFERRED_RETAIL_SHIPMENT", "RATED_ACCOUNT_PACKAGE", "RATED_ACCOUNT_SHIPMENT", "RATED_CUSTOM_PACKAGE", "RATED_CUSTOM_SHIPMENT", "RATED_LIST_PACKAGE", "RATED_LIST_SHIPMENT", "RATED_RETAIL_PACKAGE", "RATED_RETAIL_SHIPMENT", "UNKNOWN" ], </details> There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe. ----- Ticket: opw-5482949 Forward-Port-Of: odoo/enterprise#105156
This update fixes errors related to tax processing within the HR:E category and improves compatibility with the UBL tax extension. It now displays warnings for invoices that fail to fiscalize correctly, rather than silently skipping them, providing better visibility for users. This ensures accurate tax calculations and a smoother user experience.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245625 Forward-Port-Of: odoo/odoo#245028
This update resolves an issue preventing some users from submitting VAT declarations, even without specific access rights within the system. By adding temporary sudo permissions, the system now ensures all users can complete the process, improving compliance and reducing potential delays. This change enhances the user experience and simplifies VAT reporting.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492 Forward-Port-Of: odoo/enterprise#103647
This update fixes an issue where the system incorrectly prevented users from setting different cost shares for by-products based on product color. The change ensures that the total cost share for a Bill of Materials remains within the 100% limit, regardless of the specific color variant used for the by-products. This improves flexibility and accuracy in managing product costs.
Original PR description
### Steps to reproduce: - In the settings enable By-Products - Create a product with an color attribute and 2 values: white, black - Create a bom for that products and add 2 by product lines: - 1 x…
### Steps to reproduce:
- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
- 1 x comp1 with a cost_share of 50% specific to the white att-value
- 1 x comp2 with a cost_share of 70% specific to the Black att-value
#### > Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.
### Expected behavior:
The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.
### Cause of the Issue:
Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202
### Fix:
Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a
opw-5499773
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245441This update removes a problematic default payment method (`99 – Por Definir`) used in MX e-invoicing invoices, sale orders, and POS orders. This change corrects a fiscal inconsistency, particularly with the ‘PUE’ payment policy, ensuring compliance. The fix clarifies data requirements for users.
Original PR description
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE`…
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid ### Cause: In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir` ### Fix: After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank ### Steps to reproduce: - Install `l10n_mx_edi` and switch to the MX company - Create an invoice with today’s invoice date - The payment policy is set to PUE - Before the fix, the payment method is set to `Por Definir` For Sale Order and POS Order tests, it's the default value as soon as you create an order opw-5406038 Forward-Port-Of: odoo/enterprise#105220 Forward-Port-Of: odoo/enterprise#104164
This update fixes an issue where iOS users were unable to save custom star ratings for product reviews. The problem stemmed from a technical glitch that reset the rating to the default value before submission. This change ensures that iOS users can accurately submit their product ratings, improving the overall customer experience.
Original PR description
## Versions
18.0+
## Issue
On iOS devices, when submitting a product review with a custom star rating, the selected value would revert to the default (4 stars) before submission.
## Steps to reproduce
*On a laptop*
- Open Editor mode on a product eCommerce page:
- Select any product element (e.g. click on the price);
- Activate customer ratings and save.
*On a physical Apple mobile device (iPhone or iPad) or on an iOS emulator via XCode (only on MacOS)*
- Go to the product's eCommerce page:
- Move down to the "Customer Reviews" section and un-toggle it:
- Write down a review;
- Click on any star rating but 4;
- Send.
## Cause
`mouseleave` event is triggered before the rating is saved and resets the rating to the default 4-star one.
## Solution
Only trigger `mouseleave` event on devices handling them correctly and post the number of visible stars on the form.
opw-5142682
Forward-Port-Of: odoo/odoo#245135
Forward-Port-Of: odoo/odoo#234308This update resolves a bug that caused a RecursionError when producing large quantities of serial-tracked products. The issue stemmed from a process that repeatedly updated deadlines, leading to excessive recursion. This change ensures stable production runs for high-volume manufacturing.
Original PR description
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Produce the 100 units on the child MO of product C (100 backorders are created). - On the main MO (product A), click on "Prepare MO". - Attempt to produce product B. → RecursionError: maximum recursion depth exceeded. **Cause** While setting `move_finished_ids`: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806 the `deadline_date` of the final move is updated: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63 This deadline is then propagated to chained moves: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55 via: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61 This propagation retriggers the `move_finished_ids` setter recursively on other moves. The recursion depth grows with the number of generated moves, eventually exceeding Python's maximum recursion limit. opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#239648
This update resolves an issue where scale readings weren't being properly transmitted to the user interface after a measurement. Previously, the system didn't automatically send weight data following the 'read_once' action for scales. This change ensures that scale readings are now reliably delivered to the frontend, providing accurate data.
Original PR description
Since odoo/odoo#237586, events are no longer automatically sent after actions are executed. Since the `read_once` action for scales did not return a value or send an event, this meant it never returned the weight to the frontend. This commit simply returns the weight value directly from the `read_once` action. Enterprise: https://github.com/odoo/enterprise/pull/105324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the system correctly processes weight readings from the scale, even when those readings are triggered by a specific 'read_once' action. This improves the reliability of scale data integration, ensuring accurate weight information is consistently captured and used within the system. It addresses a minor technical issue related to response handling.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`.
This update resolves intermittent errors in the mass mailing functionality, specifically related to saving data and handling user interactions. The team adjusted the system's response time to ensure stability during complex operations, and also addressed a potential conflict issue within the email editor field.
Original PR description
After the previous [fix], other non-deterministic errors were revealed. It seems `200` ms is sometimes too little for operations involving multiple async calls like `save` on the mass_mailing form view, and display the style option in the `html_builder` when clicking on a block. The `body_html` field is displayed in readonly as we never need to use the editor for this field. This prevents selection/event conflicts between 2 editors at the same time which is something that we don't want to test in `mass_mailing`. [fix]: https://github.com/odoo/odoo/commit/a180d09aaf0661483670a79deedc3223a0b6e621 runbot-error-238002 runbot-error-238045 task-5866753
This update resolves a previous issue where printing was significantly delayed while waiting for printer connections. By allowing each printer driver to manage its own connection, the system now avoids long waits and ensures faster printing performance. This improves the overall user experience when generating reports and documents.
Original PR description
Before this commit, the `printer_interface_L` and `printer_driver_L` shared a single `cups.Connection` instance guarded with a `Lock`. This meant that while the interface for checking for new printers (which can take 10-15 seconds), all printers were being blocked from printing until it was finished. After this commit, each driver creates its own `cups.Connection` and `Lock`. This means they should never block each other, and prevents long pauses when trying to print. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245100 Forward-Port-Of: odoo/odoo#245012
This update corrects a technical inconsistency where employee-related fields were incorrectly marked as editable. The change ensures that fields marked as 'readonly' in the version record are consistently 'readonly' for the employee record, preventing unintended data modifications. This resolves a potential data integrity issue.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983 Forward-Port-Of: odoo/enterprise#100575
This update fixes an issue where Odoo wasn't correctly assigning a plan ID when multiple schedulers were involved in a single task. The change ensures that the correct plan ID is consistently used, improving the reliability of scheduling processes. This update was a necessary correction to the existing functionality.
Original PR description
Description of the issue/feature this PR addresses: Same pattern as in https://github.com/odoo/odoo/pull/189843 but for _compute_plan_id method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243307
This update fixes an issue where zero-percent NT/NA/EXEMPT taxes were incorrectly filtered out of downpayment calculations. Previously, these taxes weren't properly accounted for, leading to inaccurate financial reporting. This change ensures that all relevant taxes, including zero-percent NT/NA/EXEMPT, are correctly applied during downpayment creation.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245570 Forward-Port-Of: odoo/odoo#245252
This update resolves an issue where full payments on invoices with installment payment terms resulted in incorrect and duplicated cash basis tax calculations. The fix ensures that only the remaining balance's tax is recorded when a full payment is made, aligning with the intended batch processing functionality. This improves the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. This came from the fact that we didn't consider a move would be fully paid by several lines at the same time, like with installments. We now only put the leftover amount when the move is fully paid and we're on the last partial. Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches opw-5061136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244733 Forward-Port-Of: odoo/odoo#236536
This update enhances the message list functionality by providing more specific error details when loading messages fails. Previously, users only saw a generic 'Ann error occurred' message. Now, the commit displays the underlying error message, giving support teams a clearer understanding of the issue and its potential cause.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244094 Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="305" height="67" alt="Screenshot 2026-01-20 at 15 10 38" src="https://github.com/user-attachments/assets/34c546df-71e6-4055-9f85-8d85a9c89b35" /> <img width="334" height="100" alt="Screenshot 2026-01-20 at 15 09 07" src="https://github.com/user-attachments/assets/5fadd0b7-7ea0-43ca-8c28-0ac1d33650ff" /> Forward-Port-Of: odoo/odoo#245150 Forward-Port-Of: odoo/odoo#244754