Tuesday, June 9, 2026
12 changes · 18.0
New functionality added to Odoo
This update replaces the previously used Tenor GIF API with Klipy, a new GIF provider. This change is necessary because Tenor's API will be discontinued on June 30, 2026. Users can now configure a Klipy API key within the settings to continue using GIFs in Odoo.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit adds support for Klipy GIF API, as a replacement to Tenor GIF API. This is made possible with a new field to provide Klipy GIF API key, next to Tenor GIF API key, in the general settings. The Klipy GIF API key takes precedence over the Tenor GIF API Key in case both are provided. Task-5491965
This update improves the Swiss payroll payslip report by incorporating the necessary source tax rate information. This ensures accurate reporting and compliance with Swiss tax regulations for employees' payrolls.
Original PR description
This commit adds the source tax rate in the payslip report for Swiss payroll. task-4979330 Forward-Port-Of: odoo/enterprise#112842
Resolved issues and error corrections
This update resolves an error that occurred when confirming purchase orders without a linked warehouse. The fix prevents a technical issue (a 'TypeError') from stopping the order confirmation process. It ensures the system correctly handles scenarios where a delivery location hasn't been set up, improving the reliability of purchase order processing.
Original PR description
When confirming a purchase order whose Deliver To operation type is not linked to any warehouse, a traceback is raised. Steps to reproduce the error: - Install ``purchase_stock`` module with demo…
When confirming a purchase order whose Deliver To operation type is not linked to any warehouse, a traceback is raised. Steps to reproduce the error: - Install ``purchase_stock`` module with demo data - Go to Inventory > Configuration > Settings > Enable Storage Locations - Create a new warehouse > add Short Name > save - Go to Inventory > Configurations > Operations Types > Open the receipts linked to the new warehouse > Unset the warehouse > Save - Create a Purchase order > Deliver To: select the above operation type > Add a product > Confirm Order Traceback: ```py TypeError: startswith first arg must be str or a tuple of str, not bool ``` https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/models/purchase_order.py#L251-L255 When the warehouse is unset on the operation type, ``wh_stock_loc`` becomes an empty recordset. The method then calls ``_child_of(wh_stock_loc)``, which eventually evaluates ``other_location.parent_path`` inside ``startswith()``. Since ``other_location`` is empty, ``parent_path`` is ``False``, causing the traceback. https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/stock/models/stock_location.py#L457-L459 sentry-7529159473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure caused by incorrectly formatted data being passed to the system. Specifically, raw PDF content was mistakenly treated as base64, leading to an error. This fix ensures data is properly encoded, improving test reliability.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#118523
This update resolves a warning message appearing in the Point of Sale interface when editing partner records. The fix adds a placeholder component to load missing widgets, ensuring the POS functionality remains stable and reliable. This prevents potential disruptions for users.
Original PR description
Step to produce: - open pos, from partner list, open any partner record to edit Observation: - we get warning like `Missing widget: x2many_buttons for field of type many2many` in console Cause: - we do not load all the web assest in pos, hence this widgets are not loaded in registry in pos asset Fix: - we add a placeholder "DefaultField" for such missing widgets Note: - this was faced, in runbot, as it didn;'t pass the it with those warning when working on https://github.com/odoo/enterprise/pull/117527 https://runbot.odoo.com/runbot/batch/2534508/build/111089589 <img width="945" height="337" alt="image" src="https://github.com/user-attachments/assets/72ca2857-5ea6-4a64-9900-6012518f1047" /> opw-6198035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that purchase order prices, like sale order prices, correctly preserve the precise cost of products and vendor prices, even when those costs are very small. Previously, Odoo rounded these prices during purchase order calculations, leading to inaccuracies. This change improves the reliability of purchase order pricing.
Original PR description
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product…
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`. However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision. This is inconsistent with sales: sale order lines preserve very small unit prices correctly. https://github.com/user-attachments/assets/03d13596-d72b-4aee-bd37-7910a5842456 **Current behavior before PR:** A product with `standard_price = 0.001235` keeps that value on the product form. When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost. The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line. **Desired behavior after PR is merged:** Purchase order lines preserve the computed unit price precision, just like sale order lines already do. A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when sending invoices from Denmark via Peppol. Previously, the system required a country prefix ('DK') for Danish VAT numbers. Now, customers in Denmark can send invoices without the prefix, ensuring compatibility and preventing invoice processing errors.
Original PR description
Current behavior before PR: - Currently, when we include `DK` country prefix in the VAT number, it automatically computes the peppol endpoint with the `DK` prefix for customer from Denmark. - However, there are cases where the VAT number may not include `DK` country prefix, while the corresponding peppol endpoint still does. - In such situations, when sending an invoice via Peppol, the following error occurs: "Errors occurred while creating the EDI document (format: UBL BIS Billing 3.0.12): The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: - Now customer from Denmark can have vat without country prefix `DK` and peppol endpoint with prefix `DK` and can send invoice via peppol. task-6119563
This update resolves a test failure in the Sendcloud delivery module. The issue stemmed from a lack of default accounting data within the test environment, specifically a missing `account_tax` record. Adding this data ensures the test runs successfully and prevents future errors.
Original PR description
Without demo data, test `test_sendcloud_delivery_with_downpayment` fails because of the absence of a default `account_tax` > psycopg2.errors.NotNullViolation: null value in column "tax_group_id" relation "account_tax" violates not-null constraint Fixes runbot errors 243069 - 243677 - 939245
This update fixes an issue where adding a recurring product to a confirmed sales order without a linked subscription plan would cause an error. The fix prevents this by validating the product setup, ensuring a subscription plan is present before allowing recurring product additions, improving order stability.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700 Forward-Port-Of: odoo/enterprise#107691
This update simplifies invoice sending by ensuring the 'By Peppol' method is only enabled by default for customers in designated countries (GR, IT, PL, PO, RO). This reduces user confusion and unnecessary notifications related to Peppol invoice sending in these regions.
Original PR description
Current behavior before PR: - If the customer has a valid Peppol endpoint, the 'By Peppol' invoice sending method is selected by default. - For countries like 'GR,' 'IT,' 'PL,' 'PO,' and 'RO,' peppol is not mandatory or not used for sending invoice. It brings noise and it bothers the users. Desired behavior after PR is merged: - The 'By Peppol' invoice sending method is set to true by default only for customers from PEPPOL_DEFAULT_COUNTRIES. Changes Implemented: - Moved the countries 'GR', 'IT, 'PL', 'PO', and 'RO' from PEPPOL_DEFAULT_COUNTRIES to PEPPOL_LIST. - Added condition to set 'By Peppol' invoice sending method to true when customer is from PEPPOL_DEFAULT_COUNTRIES. task-6072935 Forward-Port-Of: odoo/odoo#262402
This update fixes an issue where users without HR access rights in the timesheet grid view were seeing a placeholder image instead of their avatar. The fix ensures that all users can correctly display their employee avatar within the timesheet grid, improving the user experience and visual consistency.
Original PR description
Steps to reproduce: ------------------- - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: ---------- The user does not have access to the hr.employee model. Fix: ----- In this commit, if the user does not have access to hr.employee,we fetch the image from the hr.employee.public model. task: 4461272 Forward-Port-Of: odoo/enterprise#83574
This update fixes a visual glitch where overlays (like dialog boxes) sometimes appeared twice on initial display. The change prevents unnecessary re-rendering of the overlay, resulting in a smoother and more reliable user experience. This improves the overall stability of the application.
Original PR description
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or…
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`. This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time. [1]: https://github.com/odoo/odoo/pull/169264 [2]: https://github.com/odoo/odoo/pull/154349