Wednesday, July 22, 2026
7 changes · 19.0
Resolved issues and error corrections
This fix makes an automated web interface test run consistently by ensuring an expected background search always occurs during the test. It reduces random test failures, helping keep quality checks reliable without changing user-facing behavior.
Original PR description
Before this commit, a many2one field test could sometimes fail because of an unexpected web_name_search in verifySteps. That extra call followed the `.clear()` of the input, which triggers a debounced search. Depending on the timing, that call sometimes occured before the end of the test (and the destroy of the component). Now, it is always performed. runbot error~944206 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 Forward-Port-Of: odoo/odoo#276962 Forward-Port-Of: odoo/odoo#276799
Accrual entries created for multiple sales orders now show the correct sales order reference on each stock variation line. This prevents confusion during accounting review by ensuring each line can be matched to the right customer order.
Original PR description
## Problem When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused…
## Problem When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop. ## Solution We will pull the order name directly from the order line in the current iteration. ## Steps to reproduce (Runbot v19) 1. Create a product with AVCO perpetual valuation 2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts) 3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set) 4. Create 2 separate sales orders for this product 5. Deliver both of the sales orders, do not invoice them 6. Now go to the Accounting App Review>Invoices to be issued 7. Select the 2 invoices that were created. The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear. opw-6361032
The invoicing dashboard now aligns Days Sales Outstanding data with the correct fiscal year structure. This helps finance teams rely on accurate timing and trends when reviewing invoice collection performance.
Original PR description
Invoice dashboard data, specifically DSO, was incorrectly aligned due to a mismatch in the fiscal year structure. Task-6049887 Forward-Port-Of: odoo/odoo#275880 Forward-Port-Of: odoo/odoo#261037
This fixes the website footer slideout effect so it is disabled when a page has too little content to display it properly. It also updates dynamically when content or window size changes, preventing partially hidden footers while editing or viewing short pages.
Original PR description
Following the fix [1], the original behavior was lost. Previously, the footer's slideout effect was disabled if the page content was too short, preventing the footer from being partially hidden. In the original behavior, footer slideout state was computed only once during interaction setup. If the main content height changed afterward, e.g. in edit mode: dropping or removing snippets, or resizing the window, the effect could remain enabled/disabled even though the content had become taller/shorter than the viewport. This commit adds back the behavior and makes it dynamic on resize. Steps to reproduce: - Go into edit mode - On the footer, set the "Slideout Effect" option to "Slide Hover" - Add only a single snippet on the page - Half of the footer is hidden by the hover effect, which should not happen task-6117257 [1]: https://github.com/odoo/odoo/commit/e0474c19d212d9c19fd1c3bbc9546b4258770018 Forward-Port-Of: odoo/odoo#275291
This update registers the WhatsApp Identifiers translation template so it is included in the translation workflow. It helps ensure future text updates for this feature can be properly translated across supported languages.
Original PR description
pot files must be registered there. See 9966b160972a053e051f2213846acc64d133f2a3 Forward-Port-Of: odoo/enterprise#124076 Forward-Port-Of: odoo/enterprise#124026
The emSigner signing flow now places the certificate correctly in signed PDFs after recent changes to emSigner’s interface and API. This prevents incorrectly displayed certificates and helps ensure signed documents look accurate for users.
Original PR description
Before: - Certificate added by emSigner was misaligned in the signed PDF after recent UI changes. After: - Updated coordinates to ensure the emSigner certificate is properly aligned and displayed correctly in Odoo. task-6105264
Users can now click and edit custom fields directly in the Documents list view. This removes an extra step and makes customizations created with Studio behave like standard editable fields.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102