Tuesday, February 17, 2026
11 changes · 17.0
Enhancements to existing features
This update adjusts the Indian localization to align with new requirements for GST e-invoices. Specifically, it switches to a new GST Suvidha Provider (GSP) configuration, ensuring accurate data transmission for tax reporting. This change is necessary due to recent integration updates and maintains compliance with Indian regulations.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243296
This update switches the GSP (GST Suvidha Provider) configuration for Indian GST e-invoices to align with recent integration updates. This change ensures Odoo correctly transmits GST data to the Indian tax authorities, maintaining compliance and accurate reporting. It’s a necessary update to support ongoing operational requirements.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 Forward-Port-Of: odoo/enterprise#103984
Resolved issues and error corrections
This update fixes a performance issue in the Odoo editor that caused slow response times and occasional freezes when editing large documents. The change simplifies the process of tracking document changes, resulting in a significantly faster and more responsive editing experience. This improves user productivity and overall editor stability.
Original PR description
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on…
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on every history step. This is unnecessary and leads to poor performance when handling large documents. Solution: Instead of recomputing `_isDirty` on each history step, directly mark the field as dirty whenever a history step is triggered. This provides a simpler and more efficient approach. Before fix: Each keyboard interaction to next paint takes around 200ms. <img width="596" height="272" alt="image" src="https://github.com/user-attachments/assets/6145a532-3148-46fd-ac5a-cd3f4c726067" /> After fix: Each keyboard interaction to next paint takes around 40ms. <img width="610" height="178" alt="image" src="https://github.com/user-attachments/assets/1ff9ca36-457b-4015-9f30-4fed990c2ba3" /> opw-5892291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to data inconsistencies and errors. The fix ensures that invoices are processed with the correct company details, preventing problems with cross-company data and improving data accuracy.
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
This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Now, users can properly unlink tasks from sales orders, preventing billing issues and allowing tasks to be reassigned. This ensures accurate task management and billing within the project and sales workflows.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty the Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487 opw-5215989
This update resolves an issue where consumption warnings appeared when receiving quantities for subcontracted products. The change avoids triggering the warning by skipping consumption checks during quantity updates, ensuring orders are processed correctly. This prevents inconsistencies between picking and subcontracting orders.
Original PR description
**Problem:** When recording the received quantity of a subcontracted product on the move_ids, if it is higher than the original demand, Odoo will update the consumed quantities. Since the new…
**Problem:** When recording the received quantity of a subcontracted product on the move_ids, if it is higher than the original demand, Odoo will update the consumed quantities. Since the new consumption is not based on the BoM, a consumption warning can happen due to UoM rounding. However, wizards and other actions can't trigger in this context, so instead of blocking the action, it partially completes, putting both the picking and the subcontracting order in an inconsistent state. If the picking is validated, this causes the subcontracting order to only process for the original demand and create a backorder, but the move_ids report the full demand, and its move_line_ids report the original demand. **Steps to Reproduce:** - Create a product (default settings) - Create a BoM for it via smart button, set the quantity to 12 - Add a component (new product w/default settings), 1 Unit - Set the BoM Type to Subcontracting, set Azure Interior as the subcontractor - Create a PO for Azure Interior, ordering 5 units of the product, and confirm it - Go to the delivery, set the received QTY to 6, and validate -> Check "Moves" smart button to see only 5 units of product were produced **Solution:** Since the consumption wizard can't be called in the context of _set_quantity(), we skip the consumption warning. The picking and subcontracting order will be processed correctly, but this comes with the limitation that the user will not receive a consumption warning when recording the consumption this way. opw-5168417
This update fixes an issue where input fields weren't resizing correctly in Safari and Firefox, leading to overflow. The change dynamically calculates border widths and adjusts sizing without relying on outdated browser detection methods, ensuring consistent and accurate input field behavior across different browsers.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025)
This update resolves an issue where the delivery charge was being incorrectly duplicated during Stripe Express checkout, particularly with Apple Pay and Google Pay. The fix ensures accurate delivery calculations by excluding delivery lines from the tax computation. This prevents overcharging customers and improves the checkout experience.
Original PR description
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay…
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay) 2- Set fixed price on standard delivery: 10 3- Navigate to website: add a product to cart. Use express checkout. Outcome: The delivery price is calculated twice which is wrong. Cause: --- This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount. Then we add delivery carrier `minorAmount`: https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice. Fix: --- We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines. opw-5424398
This update fixes an issue where the system incorrectly predicted taxes during XML invoice imports. Previously, it relied on customer history, even if the imported invoice only contained one tax. Now, the system accurately uses the tax data directly from the imported XML file, ensuring correct tax calculations.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%),even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. This behaviour is fixed by this PR : #246308 And this commit is part of the fix. task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves an issue where tasks remained linked to sales orders even without a related sales order line. Previously, this prevented users from properly billing tasks. Now, tasks are only linked to sales orders when there are items associated with them, streamlining billing and task management. This ensures tasks can be easily detached and re-linked when needed.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989
This update fixes an error in how holiday pay is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. Now, the system correctly uses the employee's actual 40-hour week, ensuring accurate holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied.