Daily updates from Odoo
Tuesday, February 17, 2026
15 changes · 17.0
Resolved issues and error corrections
This update optimizes how Odoo handles image processing, specifically addressing a potential memory issue that could cause slowdowns during upgrades. By preventing redundant image processing in certain scenarios, this change reduces computing time and memory usage, leading to a smoother and more reliable experience.
Original PR description
Description of the issue/feature this PR addresses: Because of the way `Pillow` manages memory, excessive image processing quickly leads to MemoryError, e.g. during upgrades. Current behavior before PR: When a readonly Image field with definied dimensions relates to another Image field of the same dimensions, there is no need to ever process the former one, since the processing will already have happened on the latter one. Still, the current code will process the image superfluously in these cases. Desired behavior after PR is merged: Extending the condition for skipping superfluous image processing to cover these cases will lead to reduced compute time and memory use. Forward-Port-Of: odoo/odoo#248834
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 resolves an issue where the 'Expenses Report' feature in the HR module would fail when attached to encrypted PDF receipts. The fix skips these encrypted files, logging a note in the report instead of causing an error. This ensures reports can be generated successfully.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: "File has not been decrypted". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where leave days weren't being allocated correctly, potentially leading to over-allocation or incorrect accrual. The fix prioritizes using accrual plan allocations first, ensuring leave days are managed effectively and don't exceed their limits. This was previously resolved in version 18.0.
Original PR description
Fixing a typo introduced in commit 211330e083baaf16279d938a2b485a8fa20083a2. Also, leave days should first use accrual plan allocation (as they can expires or will be likely to reach their maximum number of days). **This bug has already been fixed in 18.0, see community#240282.** runbot-build-error-234921 task-5449396
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 fixes an issue where pasting XML into email templates didn't always work correctly, leading to malformed content. The change ensures that pasted XML, including self-closing tags, is properly parsed and handled by the editor, improving the overall email template editing experience.
Original PR description
Problem: Pasted HTML in email templates is not properly parsed. Cause: The pasted content can be valid XML. In that case, some self-closing elements (e.g. self-closing `t` tags) are not correctly parsed by the editor, leading to malformed content. Solution: Call the `fixInvalidHTML` utility when starting the edition to normalize the content and properly handle self-closing tags. Steps to reproduce: - Open an email template. - Add some content. - Toggle to code view. - Paste XML containing a self-closing `t` tag. - Observe that the content is not properly parsed. opw-5089487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly shown when the localization wasn't installed. The fix adds a new field to the model to control its visibility, ensuring the correct display based on the installed localization.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488
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.
This update ensures that all rates displayed on the printed payslip are formatted to a maximum of 4 decimal places. This improves the clarity and consistency of the payslip output, aligning with reporting standards. The change addresses a formatting issue that could lead to overly long numbers on the PDF.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739