Daily updates from Odoo
Saturday, July 11, 2026
6 changes · saas-19.1
Enhancements to existing features
This update allows users to instantly fetch e-invoices from the Polish KSeF system directly from their Odoo interface. Previously, invoices were only synced automatically on a schedule. This new 'Fetch e-Invoices' action provides immediate control and ensures users always have the latest data.
Original PR description
Previously, bills could only be retrieved from the KSeF platform via a scheduled cron job, leaving users with no option to manually sync documents on demand. An "Import from KSeF" action has been added to the gear (cog) menu within both the list and Kanban views. Clicking this option triggers the synchronization process immediately and reloads the active view. Task [link](https://www.odoo.com/odoo/project.task/6306892) task-6306892 Forward-Port-Of: odoo/odoo#274798 Forward-Port-Of: odoo/odoo#271459
Resolved issues and error corrections
This update fixes an issue where the 'Commercial Invoice' report was incorrectly available to all companies, regardless of their location. The change restricts the report's visibility to invoices generated for Thai companies with a Sales journal type, ensuring accurate reporting and avoiding duplicate print options when other localization modules are used.
Original PR description
The "Commercial Invoice" report action had no domain, so it appeared as a print option for account.move records of any company, not just Thai ones. This caused duplicate-looking invoice print options when another localization was installed alongside l10n_th. Restrict the report's visibility to invoices whose company's fiscal country is Thailand and journal type is Sales. task-6372205 Forward-Port-Of: odoo/odoo#275213
This update resolves an issue where cloud attachments downloaded via signed URLs were saved with generic names, preventing correct display and functionality. The changes ensure that attachment names accurately reflect the original file type and are correctly handled during download, improving the user experience.
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 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#274019
This update fixes an issue where combo lines weren't being imported correctly, leading to inaccurate calculations. The fix allows users to specify combo items during import, ensuring accurate totals and proper handling of combo orders.
Original PR description
Issue: --- Importing combo lines from file is not working correctly. Combo amounts are not correctly calculated. Cause: --- Currently we cannot set `combo_item_id` field in import file, as filling it will cause import fail on `ensure_one()` being called on `lined_lines` while no line is still created. Fix: --- The proposition here is to pop the `combo_item_id` in import while creating SOLs and then writing these fields values after records are created. This will allow users to set `combo_item_id` in order to be able to import combo lines. opw-6355560 Forward-Port-Of: odoo/odoo#275069
This update ensures that customer phone numbers are consistently saved for orders placed through self-order kiosks (like payment terminals). Previously, the phone number was lost during a payment processing step. This change mirrors the behavior of email registration, ensuring accurate order information is always captured.
Original PR description
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed…
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed empty), while the email was correctly registered. Self-order (QR code / mobile) was not affected. Steps to reproduce: ------------------- * Set a POS in kiosk mode with a payment terminal * Place an order and fill in the contact information (email & phone) * Pay through the terminal * Open the order in the backend > Observe that the email is registered but the phone (mobile) is not Why the fix: ------------ The kiosk pays through a second server round-trip (/kiosk/payment), which runs _check_pos_order again on the already created order. There, 'email' falls back to the partner's email but 'mobile' was taken only from the payload. By payment time the phone is no longer in the frontend payload (it is stripped from every self-order response), so the second sync overwrote the mobile saved on the draft with an empty value. The email survived only thanks to its partner fallback. Mirror the email behaviour and fall back to the partner's phone so the mobile survives the payment re-sync, consistently with the mobile field being computed from the partner. opw-6331335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273679
This update resolves an error that occurred when multiple product images with the same content were added to a product page. The fix ensures that image IDs are uniquely identified, preventing a 'duplicate key' error during the SEO optimization process. This improves the stability and functionality of the website's SEO tools.
Original PR description
## Problem: when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback…
## Problem:
when snippets with identical images are added in the e-commerce website product page, the "Optimize SEO" option in debug mode causes an error to occur with a traceback. The traceback calls out a duplicate key in the `t-foreach` of a loop over `state.altAttributes`. the `t-key` for this loop is `img.id` which is generated by the `/website/get_alt_images` controller endpoint.
## Steps to reproduce:
1. Go to a product page and click on "go to website" smart nav btn.
2. Add a snippet with an image in the `description_ecommerce` field
3. Add a snippet with the same image in the `website_description` field.
4. In debug mode, open `site > Optimize SEO`
5. An error `Got duplicate key in t-foreach` is thrown.
## Solution:
The solution was simple to add a qualifier in the compound key generated by the controller action for the `id` field. The chosen qualifier in this case was `model['field']`. `field` is the position in the template where the image came from.
So now the keys for the two identical images go
FROM
> `${model}-${id}-${index}`
>
> 1st image of `website_description`:
> `product.template-6-0`
>
> 1st image of `description_ecommerce`:
> `product.template-6-0`
TO
> `${model}-${id}-${field}-${index}`
>
> 1st image of `website_description`:
> `product.template-6-website_description-0`
>
> 1st image of `description_ecommerce`:
> `product.template-6-description_ecommerce-0`
task-6325786
Forward-Port-Of: odoo/odoo#275374
Forward-Port-Of: odoo/odoo#272846