Daily updates from Odoo
Sunday, February 22, 2026
6 changes · 17.0
Enhancements to existing features
This update allows localization teams to more easily update chart translations, even for records protected by a 'no update' flag. Previously, changes required manual intervention. Now, localization modules can directly overwrite translations, ensuring charts are always aligned with the latest language versions and simplifying localization maintenance.
Original PR description
Currently, when loading chart template translations, existing translations cannot be overwritten for records with noupdate=True flag, even when localization updates require translation corrections.…
Currently, when loading chart template translations, existing translations cannot be overwritten for records with noupdate=True flag, even when localization updates require translation corrections. This limitation prevents proper localization maintenance, especially when: - Chart template translations need to be updated to fix incorrect or outdated translations - Localization modules need to ensure translations are synchronized with the latest chart template versions - Manual translation corrections need to be applied during localization setup or updates By adding the force_overwrite parameter, localization modules can now explicitly request to overwrite existing translations, including those protected by noupdate=True, enabling proper translation management for localization purposes. The parameter defaults to False to maintain backward compatibility and preserve existing behavior when not explicitly requested. 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
Resolved issues and error corrections
This update corrects a bug where invoice payment terms were being created in the wrong order. Specifically, the last payment term line was appearing first, causing incorrect calculations. This fix ensures payment terms are correctly associated with invoices, improving financial accuracy.
Original PR description
1. Create Payment terms with line 1: after 15 days, line 2: after 45 day 1. Create invoice and save. 2. Assign payment term Move line payment term wrong Reason: The last line of the needed terms data goes first. Video Issue: https://github.com/user-attachments/assets/9cfa352f-da9e-4dc9-b861-7e12edd377e4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents user-modified invoice data from being overwritten when account moves are posted. Previously, automatic synchronization processes reset user changes, causing frustration. This change ensures user-entered data is respected during the posting process, improving data accuracy and user experience.
Original PR description
When posting account moves, user-modified data gets overwritten due to automatic synchronization between account.move and account.move.line models. This happens because the _post() method triggers…
When posting account moves, user-modified data gets overwritten due to automatic synchronization between account.move and account.move.line models. This happens because the _post() method triggers _sync_dynamic_lines() and _sync_invoice() without protecting intentionally modified data. The synchronization mechanism is designed to maintain data consistency across related models, but it doesn't distinguish between system-generated changes and user modifications. This causes frustration when users carefully adjust invoice data only to see it reset during posting. This commit adds context flags when writing the 'posted' state to prevent unwanted data synchronization. The technical choice to use existing context flags rather than implementing a new mechanism ensures consistency with the current architecture and avoids introducing breaking changes. The posting process should respect user intent and preserve deliberately modified data. https://github.com/user-attachments/assets/ebde6bbc-c88f-4351-913a-5da85c53b95b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a layout issue on the MRP production form that caused the quantity field to overlap on smaller screens, making it difficult to read on mobile devices. The changes implement responsive design principles to ensure quantity information remains clear and accessible across all screen sizes. This improves the user experience for all users.
Original PR description
Responsive layout prevent product_qty field overlap on small screens The quantity section in MRP production form view has responsive layout issues where product_qty field gets overlapped by product_uom_id field when the screen is resized to smaller widths. This makes quantity information unreadable on mobile devices and narrow browser windows. Video: https://github.com/user-attachments/assets/5448c65e-c744-47f5-8760-0da4c6d149ea --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a calculation error in manufacturing order finish dates. Previously, the system didn't account for the ratio of actual production quantity to the standard BOM quantity, leading to inaccurate dates. Now, the system accurately calculates finish dates based on production volume, ensuring more reliable scheduling and reporting.
Original PR description
The date_finished calculation in manufacturing orders was not considering the ratio between production quantity and BOM quantity, leading to incorrect finish dates when producing quantities different…
The date_finished calculation in manufacturing orders was not considering the ratio between production quantity and BOM quantity, leading to incorrect finish dates when producing quantities different from the standard BOM quantity. Previously, the system only used the BOM's produce_delay without accounting for the actual production quantity. This caused issues when: - Producing 4 tables (BOM: 1 table) - finish date was too early - Producing 0.5 tables (BOM: 1 table) - finish date was too late - Using different UoMs between production and BOM The fix introduces a factor calculation: factor = production_qty / bom_qty final_delay = factor * bom_produce_delay This ensures that the finish date accurately reflects the actual production time based on the quantity being produced relative to the standard BOM quantity. The change maintains backward compatibility and only affects the date_finished computation when a BOM is present and the production quantity differs from the BOM quantity. https://github.com/user-attachments/assets/1c63a3ad-8859-4cd6-8605-812165ebbda1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where automatic entries weren't correctly linked to the branch journal. Previously, the system defaulted to the root company, preventing users from managing entries by branch. This change ensures automatic entries are accurately recorded in the correct branch journal, improving branch-level financial reporting.
Original PR description
**Steps to Reproduce** 1. Create a journal in the branch company. 2. Create Automatic Entries for transactions originating from the branch. 3. In the wizard, the branch's journal cannot be selected. **Cause**: The company field in the wizard is always changed to the root company, making it impossible to select the branch's journal. **Solution**: The goal was to enable the management of automatic entries for multiple entries coming from different branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr