Thursday, July 31, 2025
18 changes · saas-18.2
Enhancements to existing features
This change adds a new extension point in the stock process for calculating dates during push rules. It does not change standard behavior, but makes future customizations easier and safer for businesses with tailored inventory workflows.
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
This update prepares Odoo's Guatemala localization for a future electronic invoicing module. It allows certain test VAT numbers for Guatemalan companies and adds accounting support for fuel-related transactions, helping upcoming compliance workflows work correctly.
Original PR description
related enterprise PR: https://github.com/odoo/enterprise/pull/84036 Forward-Port-Of: odoo/odoo#205863
This update improves Hoot, Odoo’s internal unit testing system, making automated tests start faster, report results more reliably, and use less memory in headless runs. These changes are limited to the testing ecosystem, helping developers and CI pipelines catch issues more consistently without affecting normal business workflows.
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#219754 Forward-Port-Of: odoo/odoo#218770
Resolved issues and error corrections
This fix ensures the sales invoice creation test uses the correct type of data expected by the system. It helps prevent failures when custom invoice creation methods use alternative billing approaches, improving reliability for sales workflows.
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 fixes the Saudi e-invoicing VAT exemption code used for international passenger transport. The correction helps ensure invoices use the proper official code, reducing compliance and reporting errors.
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
The test invoice XML was updated so it uses the expected product data during import. This ensures the tax prediction test now verifies the intended behavior instead of passing for the wrong reason, reducing the risk of unnoticed tax handling issues.
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
This fix ensures invoice legal document downloads consistently return the expected data format, preventing errors when multiple document types are requested. It also improves support for downloading invoice documents across multiple file types, making the process more reliable for accounting workflows.
Original PR description
`_get_invoice_legal_documents` should, and is expected to, return a dict. however, if called with `filetype = all`, it returns, because of `_get_invoice_legal_documents_all`, a list which breaks calling code as they expect a dict not a list, and this part of the code is not used anywhere nor tested. - remove the line causing `_get_invoice_legal_documents` to return a list. - make `download_invoice_documents_filetype` work with multiple filetypes no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220170
Point of Sale orders paid with multiple methods now show the same payment method information in both the order list grouping and the order report. This reduces confusion when reviewing sales reports, even though multi-method payments still have reporting limits.
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#219021
Disabled subtle input groups on website forms now show their labels with the correct disabled styling in all supported layouts. This improves visual consistency and helps users clearly understand which fields are unavailable.
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
Website editors can now move through carousel slides while translating pages. This ensures all carousel content is reachable for translation, not just the first slide.
Original PR description
Since [1], in translation mode, only the first slide of a carousel was accessible for translation, as the native Bootstrap behavior was disabled by the translation overlay. This commit restores the ability to slide through carousel items. [1]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f
Dropship delivery slips using the DIN 5008 layout no longer show the vendor's VAT number under the customer's address. This prevents confusion for customers and keeps the printed delivery document 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#218757A website test now waits for live chat startup activity to finish before ending. This prevents false failures in automated checks, helping keep release validation stable without changing customer-facing behavior.
Original PR description
If im_livechat is installed and `test_systray_not_reditor_not_tester` is run, it might have started requests to `im_livechat/init` that are still running at the end of the test. Such pending requests are detected as issues by runbot. This commit adds a final step to the test that awaits a promise from livechat that guarantees that these requests are completed. runbot-184582
The voice and video settings now show a clear notification when microphone access is unavailable during an audio sensitivity test. This prevents users from seeing a technical error and makes the configuration experience smoother.
Original PR description
**Before this PR:** When you click on the `Test` Audio Sensitivity button in the voice & video configuration it would throw traceback if host doesn't have microphone permission which wasn't handled and was being displayed as an Uncaught Error. **This PR** handles this traceback and displays a toast notification. Task-4966597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archived time off types are now hidden from employee profile displays, so employees and managers only see active, relevant leave balances. This prevents outdated or inactive leave categories from creating confusion in the Employee app.
Original PR description
In this bug, if a time off type is archived, it is still displayed in employee app. Steps to reproduce the bug: 1- Create a database with employee and time off modules installed 2- Allocate a time off to an employee 3- Archive the time off type 4- Open Employee app and go to the employee profile 5- The archived days are still displayed opw-4900060 Forward-Port-Of: odoo/odoo#221196 Forward-Port-Of: odoo/odoo#217517
This fix ensures embedded videos remain visible when users edit website content fields that sanitize HTML. It makes it easier for editors to review, remove, or update videos without confusion.
Original PR description
Scenario: - Insert a video in a sanitized html field (for example event.event().description) - Save - Edit Result: the video disappear when editing, so it's hard to remove it or modify it, but reappear when leaving edition. Cause: sanitized field remove iframe, so we need to re-add the iframe when editing the page. Fix: run the code that re-adds the iframe when editing the page. opw-4919773
The restaurant appointment editor now hides the color selector when users scroll and the editing toolbar disappears. This prevents a floating color picker from staying on screen, keeping the editing experience cleaner and less confusing.
Original PR description
**Current behaviour before PR:** Steps to reproduce the issue: - Have a long text content in editable, making the container scrollable. - Select first line of the text, in toolbar open color selector. - Scroll down until the toolbar overflows and becomes hidden. Notice that the toolbar disappears when it overflows its container while color picker remains open, floating at the top of container. **Desired behaviour after PR:** Now, when the toolbar overflows and gets hidden, the color selector becomes hidden along with toolbar. Community PR: https://github.com/odoo/odoo/pull/202889 task-4581884 Forward-Port-Of: odoo/enterprise#90284 Forward-Port-Of: odoo/enterprise#84579
The Italian Libro Giornale PDF report now properly shows long descriptions in the Name column instead of cutting them off. Column spacing has also been stabilized so exported reports look consistent and easier to read.
Original PR description
Issue: In the Libro Giornale report (PDF), long descriptions in the 'Name' column were getting cut off, and column spacing appeared inconsistent in the generated PDF. These issues reappeared due to recent layout changes from commit https://github.com/odoo/enterprise/commit/233e82cf4e6908502a580be4bcd77fadd2aada53, which unintentionally removed previous fixes made to handle such cases. Fixes Applied: - Reintroduced the `o_overflow_name` class on the 'Name' column to ensure long descriptions wrap correctly and are not truncated in the PDF export. - Applied the `o_fixed_column_width` class to the 3rd column (currently 'Account Code') to resolve inconsistent spacing between columns caused by `wkhtmltopdf`. Forward-Port-Of: odoo/enterprise#91231
This update fixes an issue that caused automated checks to fail when preparing default values in Swiss payroll transmission records. It helps keep payroll-related workflows stable and prevents setup errors from disrupting validation and deployments.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/115307 Forward-Port-Of: odoo/enterprise#90487