Thursday, June 11, 2026
9 changes · 18.0
Resolved issues and error corrections
This update fixes an error in the VAT balance calculation within the l10n_uy module for Uruguay. The previous formula was inaccurate, leading to incorrect reporting. This change ensures that VAT reports accurately reflect the correct financial balances, improving the reliability of financial data.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_uy 2. Go to tax report and see the formula of the VAT balance that is incorrect ### Reason to introduce the fix: Correct the formula to display the right amount. opw-6261211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268478
This update fixes a warning related to how Odoo uses the PyPDF library to generate PDFs. The change ensures compatibility with recent PyPDF updates by adjusting the order of operations when merging and compressing PDF pages, preventing errors and ensuring stable PDF output.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/odoo#267958
This update fixes a warning related to how Odoo handles PDF document merging using the PyPDF library. The change ensures that PDF pages are processed correctly, preventing potential errors and maintaining stable document generation. This resolves a technical issue that could impact document processing reliability.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/enterprise#119239
This update fixes an issue where images weren't displaying correctly in Outlook emails. The changes backport a solution from a previous development branch to ensure consistent image rendering across different email clients, including Outlook. This improves the user experience for sending and receiving emails with images.
Original PR description
Backport the changes from `b9370ea6b70ca3020c73a6940d70ff0cf954f69f` into `mail/convert_inline` to ensure Outlook-compatible image rendering. opw-3776054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where the Urbanpiper order ticket screen incorrectly displayed customer information even after the customer was removed. The fix ensures that customer details are only shown when a customer is actually linked to the order, improving the user experience and preventing error messages.
Original PR description
Steps to reproduce: ==== - Place an order through Urbanpiper. - Edit the order and remove the customer. - Open the ticket screen and click the info button. - A traceback occurs. Cause: ==== - Customer details were rendered even when no customer was linked to the order. Fix: ==== - Display customer details only when a customer is present on the order. task-6233812
The 'Fill' option on the /shop page now correctly adjusts product image sizes based on the selected 'cover' or 'contain' mode. Previously, the toggle had no effect. This change resolves a visual inconsistency and ensures the product images display as intended.
Original PR description
**Problem:** On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails. **Steps to…
**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.
**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.
**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.
**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`
**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.
**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.
opw-6231432
Forward-Port-Of: odoo/odoo#266717This update fixes an issue where refunding a partially paid Point of Sale order incorrectly displayed the total and line amounts. Previously, the system showed the original order's total, even after multiple refunds. This change ensures accurate refund calculations are reflected in the PoS system, improving financial reporting and order management.
Original PR description
When refunding an order that has already been partially refunded, the line amount and total amount where incorrect. They would be the total amount of the original order. Steps to reproduce: ------------------- * Open PoS and make an order with 3 quantity of a product. * Close the session * In the backend, refund 1 quantity of the order and validate the refund * Refund again the same order with the 2 remaining quantities > Observation: The total amount and line amount are not correct opw-6215019 Forward-Port-Of: odoo/odoo#265322
This update fixes an issue where Odoo cron workers weren't efficiently managing database connections. By introducing a new configuration setting, we can now tailor the memory limits for cron workers, preventing unnecessary database cycling and improving overall performance. This ensures cron jobs run smoothly and efficiently.
Original PR description
The configuration option `registry_lru_size` does not exist and does not work at all in recent versions. Defining odoo-specific environment variables to handle: - ODOO_REGISTRY_LRU_SIZE: the default registries size - ODOO_REGISTRY_LRU_SIZE_CRON: overwrite for cron workers Cron workers have often a different workload than HTTP workers and we may set a different limit there. If the limit is lower than the number of databases, a cron job will not reuse registries because it cycles through all known ones - in such cases, we can set a lower limit to keep the memory lower. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268587
This update resolves a crash in the HTML editor when pasting tables containing header cells (like those from Word). Previously, selecting these headers caused an error. Now, the editor handles tables with headers correctly, ensuring a smooth user experience when pasting and editing HTML fields.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: When a pasted table contains <th> header cells (common from Word paste), selecting them and triggering a toolbar refresh crashes because closestElement(node, "td") returns null for headers and the code then calls getBoundingClientRect() on null. Match "td, th" instead and bail out early when no cell ancestor is found. Desired behavior after PR is merged: No errors when selecting or drag/drop Steps to reproduce: 1. Open a record with an HTML field (e.g. a sales order Terms and Conditions). 2. Paste a table that has <th> cells in the first row (copy from Word or use raw HTML). 3. Select text across the header cells and drag/drop or click outside. 4. Expected: nothing happens. Actual: TypeError "Cannot read properties of null (reading 'getBoundingClientRect')". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr