Friday, May 15, 2026
13 changes · 19.0
Enhancements to existing features
Accounting line updates now skip unnecessary reconciliation checks when there is nothing to undo. This reduces avoidable database work and can make routine accounting updates faster without changing user-facing behavior.
Original PR description
Since `write` is often done record by record because the values written are different on all lines, the call to `action_undo_reconciliation` is actually not batched. Even if there is nothing to do, some queries are still done to make sure that there is nothing to do...
Automated code execution now lets certain database conflict errors pass through so the system can retry them correctly. This makes behavior more consistent and can reduce avoidable failures when temporary database constraints or concurrency issues occur.
Original PR description
It makes sense to bubble up the `psycopg2.IntegrityError` (as well as the subcase `ConcurrencyError`) so that the retry mechanism can handle this exception. In fact, this exception can be triggered without necessarily a problem with the "logic/business code". This ensures consistent behavior between the business logic and the code executed in `safe_eval`. Task-6215886
This update aligns report subheaders and numeric data within reports to create a more consistent and professional appearance. Previously, the formatting was inconsistent, with subheaders centered and data aligned differently. This change ensures a uniform look across all reports, enhancing readability and user experience.
Original PR description
Before this commit, subheaders of numeric columns were centered, while the figures in the columns were aligned to the end. This commit ensures that both the subheader and the figures are aligned the same way (center or end). task-6197223
Resolved issues and error corrections
Sale orders will no longer show the Manufacturing Order shortcut when the product is fulfilled through subcontracting. This keeps users focused on the correct purchase and subcontracting receipt workflow and avoids confusion from opening back-end manufacturing records that are not the right place to manage the process.
Original PR description
The Manufacturing Order (MO) smart button on a Sale Order is confusing when the product is subcontracted. In a subcontracting flow, the user manages the process via the Purchase Order and the Subcontracting Receipt. This commit ensures the MO smart button is hidden when the fulfillment is handled through subcontracting to prevent user confusion and unnecessary navigation to back-end manufacturing documents. Task-id: 6173877
Code cleanup and technical improvements
This update centralizes how website-related plugins define which submit buttons should be handled specially in the page builder. It makes future changes easier and reduces the need to alter core code when adding or updating plugins.
Original PR description
\* = website, website_mass_mailing, website_payment Previously submit button selectors were hard coded in multiple places (e.g. save snippet and clone logic). This made the list harder to maintain and required modifying the base code whenever a new plugin needed to exclude its submit button. Introduce a resource allowing plugins to register their own submit button selectors. Plugins can now extend this list directly from their code without modifying the base implementation. This makes the logic easier to maintain and provides a reusable extension point for other submit-button related behaviors in plugins. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252679
Documentation and clarification updates
This pull request adds an individual Contributor License Agreement record for a contributor. It is an administrative legal update that supports contribution compliance and does not change product behavior.
Original PR description
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
This fix ensures a broad yes-or-no filter is simplified before deeper search logic runs. It helps prevent errors in specialized searches and keeps results consistent for users.
Original PR description
When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change reverses a previous stock delivery slip update that depended on barcode-specific packaging data. It prevents standard stock transfers from referencing information that may not exist unless the barcode app is installed, helping avoid display or reporting issues.
Original PR description
This reverts commit efab5c52569d64e6d73cacf7611a40b025df52fb. `packaging_uom_id` only exists on `stock.move.line` once the stock_barcode module is installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Pressing Enter at the end of a styled heading now creates a clean blank paragraph instead of copying the heading's color or other styling. This prevents unwanted formatting from spreading while editing website or document content, making text editing more predictable for users.
Original PR description
Problem: Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles. This is no longer the expected behavior. The new paragraph should be empty and without inherited styles. Solution: When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles. Steps to reproduce: - Add a heading. - Apply a style (e.g., color). - Place the caret at the end of the heading. - Press Enter. - Observe that the new paragraph still has the heading color. task-6147897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264369 Forward-Port-Of: odoo/odoo#262150
This update resolves an issue where overtime calculations weren't correctly accounting for lunch breaks. The fix adjusts the overtime check to consider lunch hours, ensuring more accurate overtime tracking. This change was prompted by a related update in the Odoo community repository.
Original PR description
**Version:** - 19.0 **Issue:** - test_14_overtime_rule_per_day_period test case was failing due to the changes in the community PR. **Fix:** - Updated the overtime check_work_entries to take lunch hours in consideration. **Community PR:** - https://github.com/odoo/odoo/pull/257079 **Task-6064081**
This update corrects a technical error that occurred when loading paid orders. The previous process incorrectly referenced an account move, which was already being handled by another part of the system. This change ensures paid orders load correctly and efficiently.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467
This update fixes a reporting issue in the Peruvian Profit & Loss report. Previously, depreciation entries were incorrectly categorized as 'Other Income'. The change ensures that depreciation entries (expenses) are now correctly classified within the 'Other Operating Expenses' section, providing accurate financial reporting for Peruvian businesses.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a necessary data state within the test file, ensuring the tests now run successfully. This prevents disruptions to the Italian reporting functionality.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#117001 Forward-Port-Of: odoo/enterprise#112794