Thursday, July 31, 2025
23 changes · saas-18.4
Enhancements to existing features
This update improves Odoo's internal JavaScript testing tools, making test runs faster, more reliable, and easier for developers to manage. The changes are limited to the test ecosystem, reducing risk to business features while helping teams detect issues more efficiently.
Original PR description
## Pull Request HOOT (PRHOOT) 35 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220298 Forward-Port-Of: odoo/odoo#218770
A previously disabled website editor test has been updated to work with the redesigned website builder. This helps ensure editor access restrictions continue to be checked reliably during development.
Original PR description
This commit adapt the broken tests test_05_specific_website_editor.
This update adds a new extension point in the stock module for customizing how dates are calculated during stock push operations. It does not change existing behavior, but makes future adaptations easier and safer for custom implementations.
Original PR description
This eases inheritance. No behavior is changes with this PR, it is just a new inheritance point. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217888
Resolved issues and error corrections
This fix prevents pop-up interface elements from crashing when a user navigates away while they are still open. It improves stability in the web interface by ensuring the close behavior always receives the expected page element.
Original PR description
The popover component's 'closeOnClickAway' prop is expected to receive an HTML element as first argument. Before this commit, when navigating with an open popover, it tried to close by giving no argument to the callback, as it is expected to be an element on which the user clicked, that would cause the popover to close. The issue is that even though there was no click per se, the callback still expects an element and may crash when given none. This commit arbitrarily gives the document element (<html>) to the callback when the window is the event target to prevent such crashes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221323
Point of Sale orders paid with multiple methods now show the same payment method in both the order search view and the report. This reduces confusion when reviewing sales grouped by payment method, though multi-method orders still have an inherent display limitation.
Original PR description
Previously, orders with multiple payment methods showed different methods in the search view and the report. This remains a technical limitation of multi-method payments, but the behavior is now consistent. Steps to reproduce: ------------------- * In PoS create and validate an order paid by cash AND card * In the backend go to Reporting > Orders * Select Group By : Payement Method * Open the Report of your order > Observation: On the report, the method usually was the first one used but not in the search view opw-4851249 Forward-Port-Of: odoo/odoo#221289 Forward-Port-Of: odoo/odoo#219021
The HR settings page no longer shows an outdated option for enabling contracts, because contract features are now included directly in HR. This avoids confusion for administrators while keeping the setting safely enabled behind the scenes.
Original PR description
When `hr_contract` was merged into `hr` we forgot to remove the field from `res.config.settings`. To be stable-friendly we hide the field in the view, and make it readonly and such that it always shows as True. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website image gallery testing flow was adjusted to avoid intermittent failures when image editing tools load or images are removed. This helps keep quality checks stable so website-related changes can be validated more reliably.
Original PR description
This commit fixes an unstable tour related to the image gallery snippet, which could fail intermittently. The failure was not only caused by the image being removed before its size was computed, but also by a race condition where `activateCropper()` was triggered before the `html_editor.assets_image_cropper` bundle finished loading. runbot-229949
This fix ensures products correctly show the "Available in Self Order" option when a point of sale uses self-ordering without category limits. It helps staff manage product visibility consistently and avoids confusion when configuring self-order menus.
Original PR description
Before this commit, in a PoS config with self-ordering and no category limit, the "Available in Self Order" field was incorrectly missing for some products that should have displayed it. opw-4914554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217105
Dropship delivery slips using the DIN 5008 layout no longer show the vendor's VAT number under the customer's address. This prevents misleading customer documents and keeps the delivery slip focused on the correct recipient information.
Original PR description
When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it. This is misleading.…
When printing the delivery slip of a dropship operation using the DIN 5008 layout, the customer's address is correctly displayed, but the VAT of the vendor is shown beneath it. This is misleading. Actually we do not need vat at all.
**Step to reproduce:**
- Install `l10n_din5008_stock` and `sale_management`
- Go to setting
-> configure document layout -> set `DIN 5008` as layout
-> enable `dropshipping`
- Create a product, enable Purchase, and select Dropship route.
- Assign Azure Interior as the vendor in purchase tab.
- Create a SO with that product and Deco Addict as customer, confirm it
- Click on purchase smart button, confirm it, click on dropship smart button
- print delivery slip Observation: Below the customer's address, the vendor's VAT is printed.
**Issue:**
- issue lies in this condition
- `not (o.picking_type_id.code == 'outgoing' and main_address.id != o.partner_id.commercial_partner_id.id)`
- as `o.picking_type_id.code` is `dropship`
- here, condition evaluates to true, which incorrectly assumes the customer and vendor is same, and prints partner i.e vendor's VAT
**Fix:**
- no need to display vat,so we remove it
<img width="1519" height="244" alt="image" src="https://github.com/user-attachments/assets/d8630fa5-c568-4208-a97e-7e4ceb371109" />
**Before**
<img width="803" height="366" alt="image" src="https://github.com/user-attachments/assets/e2148bb0-7413-4efe-b312-ba7a577e0b62" />
**After**
<img width="615" height="244" alt="image" src="https://github.com/user-attachments/assets/526cfae3-4d8b-4755-b59c-54dfce79526c" />
opw-4929680
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#218757Disabled subtle input groups on website forms now apply the correct visual style to their labels in all label positions. This makes disabled fields clearer and more consistent for visitors and editors.
Original PR description
Prior to this commit, the disabled state of subtle input-group worked partially. Depending on the type of input and the position of the label (before or after the input), the disabled style was not correctly applied to the label. This commit adapts the style to cover all possibilities. task-4930086 | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217891
The website test flow now waits until the page content has fully loaded before continuing. This reduces intermittent automated test failures and helps keep release validation more stable.
Original PR description
Previously, the tour step executed too quickly and did not wait for the page iframe to fully load, causing intermittent failures. This commit ensure the tour only proceeds after the iframe is completely loaded. runbot-230309
This fixes a visual issue in the HTML builder where a decorative line could appear too tall when a row contained larger content than its label. The change keeps the line aligned with the label, improving visual consistency without changing functionality.
Original PR description
When a `BuilderRow`'s content is bigger than its label (e.g.: a `BuilderSelect` with an image vs. a one-word label), the sublevel decoration line in front of it is too big. This is because the line is set as a pseudo-element on the `.hb-row` instead of it's label, with a 100% height. Adapting it to the `.hb-row-label` fixes it.
The test invoice XML was corrected so it uses product data that exists in the test setup. This ensures the tax prediction test checks the intended behavior rather than passing because of a fallback, improving confidence in electronic invoice tax handling.
Original PR description
Previously, the test XML file included a product that did not exist in the test environment. As a result, on import the aml could not retrieve the product. Due to this, the _predict_taxes method in _onchange_name_predictive was invoked, which ended up assigning the correct tax. This caused the test to pass without actually verifying the behavior of the _predict_specific_tax. With this **PR** test xml has now been updated to properly focus on and validate the _predict_specific_tax method behavior. **task**-4943015 Enterprise PR - https://github.com/odoo/enterprise/pull/91224 Forward-Port-Of: odoo/odoo#219911
Printer drivers now receive the session information needed to send a completion event when a print job finishes. This helps ensure users and connected systems are properly notified when printer work is done, reducing missed status updates.
Original PR description
We now provide the session_id to printer drivers to ensure we create an event when the printers notifies it job completion. Enterprise PR: https://github.com/odoo/enterprise/pull/91356
This fixes the Saudi e-invoicing exemption reason code used for international passenger transport. The correction helps ensure tax documents use the proper official code and reduces the risk of compliance issues.
Original PR description
The code for The international transport of Passengers was wrong. It was VATEX-SA-34-1 instead of VATEX-SA-34-2. This commit fixes the code. task-id: 4949581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219981 Forward-Port-Of: odoo/odoo#219301
This fix ensures the sales invoice creation test uses the correct type of data when calling invoice creation logic. It helps avoid failures in customized sales workflows that use alternative invoicing methods, improving reliability for partners and customers with customizations.
Original PR description
At [1], `_create_invoices()` expects a recordset, not a dictionary. The test case currently passes because the `advance_payment_method` is set to `percentage`. However, if someone overrides `_create_invoices()` and uses a different `advance_payment_method` (e.g., 'delivered'), it will fail. Traceback: --- `AttributeError: 'dict' object has no attribute '_create_invoices'` [1]- https://github.com/odoo/odoo/blob/4cd24dc73d46b714cd5a764ed3f003e9507b0777/addons/sale/tests/test_accrued_sale_orders.py#L150-L152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220755
This fix ensures the correct Point of Sale configuration is shown in the Belgian blackbox installation banner. It also restores missing labels on IoT device attribute fields, making the forms clearer and reducing setup confusion.
Original PR description
We fixed the associated pos config displayed inside the "install pos_blackbox_be" banner and the labels of attributes not showing on the iot device form.
This fixes a crash in Odoo Studio when users edit certain bank-related fields on contact accounting tabs. Users can now open and customize these fields without interruption, improving reliability for configuration work.
Original PR description
Example of steps: - Install contacts, web_studio and accounting - Go to contacts, accounting tabs - Open web_studio and click on Banks field - Traceback The error stems from the fact that we are using a widget in an o2m field that uses a placeholder that is not defined for o2m. One solution is to add the placeholder attribute for o2m in addition to m2m and m2o. opw-4937447 Forward-Port-Of: odoo/enterprise#91346
Italian companies can now post tax closing entries from the Accounting Dashboard without hitting an error. The fix ensures the correct journal entry is used when validating the posting wizard, preventing a crash in this workflow.
Original PR description
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a…
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' object has no attribute '_get_report_options_from_tax_closing_entry' ``` **Cause:** When the user tries to post the closing entry from the accounting dashboard, its active_model is `account.journal`, and the active_id should be the current id of the miscellaneous journal. This leads to the above traceback, as the method `_get_report_options_from_tax_closing_entry` is not available in account.journal. **Solution:** To resolve this issue, we can browse the current move from the `ctx['l10n_it_moves_to_post']`, since the value of the `l10n_it_moves_to_post` is also self.ids. Which is the current active id for that closing entry. https://github.com/odoo/enterprise/blob/3d89d9fe6be8e789278dee9bc706e091ee5a0ec5/l10n_it_xml_export/models/account_move.py#L19 opw-4783958 Forward-Port-Of: odoo/enterprise#88743 Forward-Port-Of: odoo/enterprise#86791
This change restores product barcode lookup records that were accidentally removed as demo data. Keeping this core data ensures the barcode lookup features continue to work reliably for product and website workflows.
Original PR description
Reverting part of f7ad739fd4b4c90cac70af50452ebef69f07c785 because those were master (not demo) data that should be kept.
Payroll payment reports now use the company linked to the payslip batch instead of the company currently selected by the user. This prevents confusion and helps ensure multi-company payroll reports show the correct company information.
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#90886 Forward-Port-Of: odoo/enterprise#81812
Products with GST rates above or outside 5% now include the required packaged-good tag when synced to Swiggy and Zomato. This helps ensure product information is classified correctly on delivery platforms, reducing menu sync issues for Indian point-of-sale users.
Original PR description
*: pos_urban_piper_swiggy, pos_urban_piper_zomato Before this commit: --- - Products with GST != 5% were not receiving the `packaged-good` tag in the sync payload for Swiggy and Zomato. After this commit: --- - Now, products with GST != 5% correctly include the `packaged-good` tag in their respective provider tag list (`swiggy` or `zomato`). task-4954571 Forward-Port-Of: odoo/enterprise#91278 Forward-Port-Of: odoo/enterprise#90595
A small robustness fix prevents the Belgian point of sale certification component from failing when expected data is missing. This reduces the chance of checkout interruptions caused by incomplete values.
Original PR description
We increased the code robustness by ensuring the variable isn't undefined before using `.startsWith`