Tuesday, July 8, 2025
16 changes · 18.0
Enhancements to existing features
The Spanish SII electronic invoicing module updates its AEAT demo certificate used for testing and validation. This helps keep localization test data current so related workflows can continue to be checked reliably.
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 Forward-Port-Of: odoo/odoo#217341
This update makes an internal account follow-up check clearer and less prone to confusion when identifying related accounting records. It helps reduce the risk of errors in payment follow-up processing without changing how users interact with the system.
Original PR description
Refactored the SQL construction for checking the existence of related account.move records for res.partner entries. The account.move query is now built separately and referenced explicitly, making the code more readable and reducing the chance of ambiguity in field resolution. Using `SQL.identifier(query.table, "id")` ensures that the correct table is referenced in each condition, which is particularly important when dealing with multiple joins or subqueries.
This update keeps POS IoT scale validation aligned with recent Toledo scale error checks. It helps ensure connected weighing scales continue to report weights reliably after the related scale-handling changes.
Original PR description
This PR adapts the scale checksum to the PR adding the error checks to Toledo scales: https://github.com/odoo/odoo/pull/217674
Resolved issues and error corrections
This fix adjusts automated login flow checks so the two-step authentication step is only monitored when it is actually active. It helps prevent false test failures around sign-in and improves confidence in the authentication process.
Original PR description
In this commit, we change the login page step by a step with isActive property. So this step is only active when the input#login is not on the page and then expectUnloadPage will be only listen when this step is active. 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
Miscellaneous changes
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible w
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213410 Forward-Port-Of: odoo/odoo#201583
This fix ensures the background-position editing overlay fills the full area of affected website snippets. It helps editors accurately adjust background images and keeps related tooltips positioned correctly.
Original PR description
Before this commit in some snippets background overlay wouldn't have
proper height and/or width because of the snippets `h-{}, w-{}` classes.
This commit overrides it with `!important`.
To reproduce the issue:
- open website and start editing
- drop columns snippet, add background image to one of the cards, click
on it
- Click on the background position option to change it(the one with
a crosshair icon)
- the overlay isn't shown properly, which also breaks the tooltip
position
This should be forward-ported up to 18.3 inclusive, and from 18.4 on, `background_position_overlay.js L135` should be changed because of the [html_builder refactoring].
task-4930050
[html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbThis fix corrects mismatched formulas in the POS HR spreadsheet dashboard. Business users should see more reliable dashboard figures when reviewing point-of-sale and employee-related reporting.
Original PR description
Task: 4930419 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
Long spreadsheet dashboard names in the search panel now show in full when users hover over them. This makes it easier to identify dashboards without changing the panel layout or requiring extra clicks.
Original PR description
Before this pr: - Long dashboard names were truncated in the search panel. - There was no way for the user to see the full name. After this pr: - A tooltip has been added to display the full dashboard name on hover. Task: [4903713](https://www.odoo.com/odoo/2328/tasks/4903713) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216578
Stock report PDFs now show table headers in bold as expected, matching the formatting users see in the report template. This improves readability and keeps printed inventory documents visually consistent.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380 enterprise PR: https://github.com/odoo/enterprise/pull/87852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents electronic invoice generation from failing when an invoice line contains a tax detail without a grouping key. The system now skips those incomplete tax details when building export tax categories, improving reliability for UBL/CII invoice exports.
Original PR description
Before this commit: If a tax detail of an invoice line has the None tax grouping key, there is a traceback when generating the UBL InvoiceLine/ClassifiedTaxCategory After this commit: We exclude tax details that have the None grouping key when generating the InvoiceLine/ClassifiedTaxCategory. task-none
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PDF reports now show table headers in bold as intended, matching the formatting users see in the report template. This makes printed inventory reports clearer and more consistent for users who rely on PDF outputs.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380
This fix prevents Uruguay electronic invoicing from failing when a user clears a journal item description. It ensures invoices can still generate the required tax authority XML without an unexpected error.
Original PR description
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description automatically populates with the product name upon line creation. However, users can intentionally clear this field. If the description field becomes empty, its value is interpreted as `False`. This leads to an `AttributeError: 'bool' object has no attribute 'replace'` traceback when the `_l10n_uy_edi_get_line_nom_and_desc` method attempts to process this boolean value, as it expects a string. This issue specifically affects the generation of the "DscItem" tag in the XML file sent to DGI. ### Solution: To prevent this error, an additional validation has been implemented for the line description. This validation ensures that if the field's value is `False`, it is not processed by the `_l10n_uy_edi_get_line_nom_and_desc` method, thus avoiding the traceback.
This update adds validation for a specific return scenario involving intercompany dropship orders. It helps ensure these returns continue to work correctly and reduces the risk of regressions in multi-company sales and purchasing flows.
Original PR description
Adds test coverage for return of an intercompany dropship use-case (see corresponding community PR). opw-4526750
Budget reports now avoid creating an extra duplicate line when a purchase order includes a negative discount line. This keeps budget figures accurate and prevents overstating discounted amounts in purchase-related budget views.
Original PR description
Steps to reproduce: - Create a new Budget with budget line having Project [TEST] - Create a purchase order with 2 lines: 1. Product A, analytic [TEST], price unit 100, qty 1 2. Product B, analytic [TEST], price unit -10, qty 1 - Confirm the PO, mark products as received - Create the bill and confirm - Go back in PO, click on Budget smart button, open list view Issue: The budget report will correctly show a line for each invoiced line, but an extra line with double discount amount is present Occurs because we use a SQL code to replicate the qty_invoiced field of a purchase order line, but we adjust the sign based on the aml balance instead of taking into account the move type opw-4775631
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible w
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#87228 Forward-Port-Of: odoo/enterprise#81354