Monday, June 29, 2026
9 changes · 19.0
Resolved issues and error corrections
This fix keeps Odoo's Debian package installable on newer Debian and Ubuntu releases where an older PDF library package is no longer available. It allows the installer to use either the newer or older compatible package, preserving compatibility across supported Linux versions.
Original PR description
see odoo/odoo#233667 Description of the issue/feature this PR addresses: When building the Odoo Debian package on Debian Trixie (or Ubuntu Noble), the build system resolves the flexible dependency…
see odoo/odoo#233667 Description of the issue/feature this PR addresses: When building the Odoo Debian package on Debian Trixie (or Ubuntu Noble), the build system resolves the flexible dependency python3-pypdf2 | python3-pypdf to a fixed dependency on python3-pypdf2. However, Debian Trixie has removed the python3-pypdf2 package in favor of python3-pypdf. This makes the resulting .deb package uninstallable on Trixie due to unmet dependencies. Current behavior before PR: The generated .deb package contains a hard dependency on python3-pypdf2, causing installation failures on Debian Trixie systems with the error: Depends: python3-pypdf2 but it is not installable. Desired behavior after PR is merged: The generated .deb package contains a flexible dependency python3-pypdf | python3-pypdf2. This allows the package to be installed on both Debian Bookworm (which has python3-pypdf2) and Debian Trixie (which has python3-pypdf), as APT can satisfy the dependency with either available package. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale receipts now display change due to customers as a positive amount instead of a misleading negative value. This makes printed receipts clearer and avoids confusion when customers overpay with cash.
Original PR description
**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value…
**Issue:**
The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total.
**Before:**
The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers.
**After:**
The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`).
**Steps to Reproduce:**
1. Open a Point of Sale session
2. Add products to the cart (example total: `$49,496.00`)
3. Select the **Cash** payment method
4. Enter an amount greater than the order total (example: `$55,000.00`)
5. Observe that the **Change** field displays a negative value
6. Confirm the payment
7. Print the receipt and observe that the change amount is also negative
## Root Cause
The receipt template rendered the raw `order.change` value:
**Before**
```xml
<span t-out="formatCurrency(order.change)"
class="pos-receipt-right-align font-monospace"/>
```
Since `order.change` stores the change amount as a negative value, rendering it directly resulted in an incorrect display on the printed receipt.
---
## Fix
Negate the internal value before formatting it for display.
**After**
```xml
<span t-out="formatCurrency(-order.change)"
class="pos-receipt-right-align font-monospace"/>
```
This converts the internally stored negative change amount into the expected positive value on the printed receipt.
---
Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)]
opw-6211988
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269966
Forward-Port-Of: odoo/odoo#264681The packaging rules now keep support for either available PDF dependency, so Odoo can be installed on both current and newer Debian releases. This prevents installation failures on Debian Trixie while preserving compatibility with existing Ubuntu and Debian environments.
Original PR description
see odoo/odoo#233667 Description of the issue/feature this PR addresses: Odoo code has already adapt `python3-pypdf2 | python3-pypdf`, but during build in docker which is Ubuntu/Noble still has…
see odoo/odoo#233667 Description of the issue/feature this PR addresses: Odoo code has already adapt `python3-pypdf2 | python3-pypdf`, but during build in docker which is Ubuntu/Noble still has `python3-pypdf2` only will solve this into a fixed single `python3-pypdf2`, leading trixie which has `python3-python` only cannot adapt the built deb. Current behavior before PR: The generated .deb package contains a hard dependency on python3-pypdf2, causing installation failures on Debian Trixie systems with the error: Depends: python3-pypdf2 but it is not installable. Desired behavior after PR is merged: The generated .deb package contains a flexible dependency `python3-pypdf | python3-pypdf2`. This allows the package to be installed on both Debian Bookworm (which has python3-pypdf2) and Debian Trixie (which has python3-pypdf), as APT can satisfy the dependency with either available package. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Imported XML bills now keep product quantities at the expected precision when linked to purchase orders. This prevents tiny decimal conversion errors from causing an incorrect invoiced quantity, such as showing 1800.01 instead of 1800.0.
Original PR description
When importing an XML bill and linkin git to a purcahse order, the invoiced quantity may be computed incorrectly, due to a decimal precision mismatch. Steps to reproduce: - Import an XML bill having a line with quantity 1800.0 - Link to a purchase order with the same line Issue: The invoiced quantity will be computed with 1 cent difference (1800.01) Analysis: Because the system forced a decimal precision of 13 for 'Product Unit of Measure', quantity is imported as 1800.0000000000016. Later, when computing the invoiced quantity, the system round the quantity using 'UP' strategy, rounding the amount to 1800.01 opw-6194824 Forward-Port-Of: odoo/odoo#270916 Forward-Port-Of: odoo/odoo#266283
This fix ensures event participants see the appropriate success message after completing a track quiz. It improves the attendee experience by avoiding misleading feedback when quiz results are displayed.
Original PR description
opw-6332274 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#272371
This fix keeps Odoo's Debian package dependency flexible so it can install correctly on both older and newer Debian releases. It prevents installation failures on Debian Trixie where the older PDF library package name is no longer available.
Original PR description
Flex dependency `python3-pypdf2 | python3-pypdf` will be fixed to `python3-pypdf2` during building deb in Docker/Noble. see odoo/odoo#233667 Description of the issue/feature this PR addresses: Odoo…
Flex dependency `python3-pypdf2 | python3-pypdf` will be fixed to `python3-pypdf2` during building deb in Docker/Noble. see odoo/odoo#233667 Description of the issue/feature this PR addresses: Odoo code has already adapt python3-pypdf2 | python3-pypdf, but during build in docker which is Ubuntu/Noble still has python3-pypdf2 only will solve this into a fixed single python3-pypdf2, leading trixie which has python3-python only cannot adapt the built deb. Current behavior before PR: The generated .deb package contains a hard dependency on python3-pypdf2, causing installation failures on Debian Trixie systems with the error: Depends: python3-pypdf2 but it is not installable. Desired behavior after PR is merged: The generated .deb package contains a flexible dependency python3-pypdf | python3-pypdf2. This allows the package to be installed on both Debian Bookworm (which has python3-pypdf2) and Debian Trixie (which has python3-pypdf), as APT can satisfy the dependency with either available package. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Neutralized databases will now use the VIES test endpoint instead of the live production service when no custom endpoint is configured. This prevents test or anonymized environments from unintentionally contacting the real VAT validation service, reducing operational risk without affecting customized setups.
Original PR description
Neutralized databases don't always have demo data, so they talk to production VIES endpoint. With this change, the production endpoint is replaced with the test one. If some database has a custom endpoint, nothing is done. @moduon MT-15142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272036
This fixes an error that appeared when users removed the currency while registering a payment in the Argentine withholding workflow. The payment form now handles an empty currency safely, preventing disruption during invoice payment processing.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255825
This fix prevents an error that could appear in Chrome when users open a menu popover in Knowledge. It keeps the interface working reliably when pages include embedded content from another origin.
Original PR description
Steps to reproduce ================== - Install knowledge - Go to knowledge - Click on the three dots at the top right => SecurityError Cause of the issue ================== Since https://github.com/odoo/odoo/commit/8719c81744431d9fb862821430ce4558e2317b71 , We try to intercept clicks on iframes. In Chrome, accessing iframes from a different origin throws a SecurityError opw-6344024