Monday, July 13, 2026
22 changes · saas-19.4
New functionality added to Odoo
This update provides Russian translations for the Chart of Accounts data within the Odoo localization module for Uzbekistan. Recognizing the widespread use of Russian in Uzbek accounting, this change expands Odoo's usability and adoption among local users. This supports a key market and improves the overall user experience.
Original PR description
This change adds Russian translations for the Chart of Accounts data in the l10n_uz module. Standard practice is to enable only a country's official statutory language in localization modules However, the business reality of Central Asia particularly Uzbekistan justifies an exception: Russian is widely used in accounting practice there, and supporting it will significantly improve adoption among local users. task-6229114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274137 Forward-Port-Of: odoo/odoo#269320
Enhancements to existing features
Uzbekistan financial reports now include Russian translations alongside Uzbek. This helps businesses in Uzbekistan use Odoo reports more easily in a commonly used business language, improving local adoption.
Original PR description
Uzbekistan's business environment requires Russian in addition to the official Uzbek language to ensure adoption. While localizations typically activate only statutory languages, Central Asian market realities justify this exception. task-6229114 -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#122901 Forward-Port-Of: odoo/enterprise#120250
Resolved issues and error corrections
The social CRM feed now shows the correct post actions instead of an empty menu. Feed refreshes are also more reliable because batch requests are given more time to complete.
Original PR description
Bug 1 === Since b75755ea8ac65ce5ce973412e3c4194fa1bd6fd3 , the menu on the stream post could be visible but empty. The reason is that we checked for `this.isConvertibleToLead` instead of `this.isConvertibleToLead()`. We take advantage of this bug fix to correctly overwrite the condition without replacing the entire button (which can break other module overwriting the same element). Bug 2 === Sometimes, when refreshing the feed view, an error occurs because the request timeout. To fix it, we increase the timeout when doing requests in batch. Task-6254983 Forward-Port-Of: odoo/enterprise#118329
Features or functions removed from Odoo
The Belgian payroll rules now stop applying the elderly worker reduction in Brussels starting in the third quarter of 2026. This keeps payroll calculations aligned with the updated regional rules and updates related checks accordingly.
Original PR description
removed the reduction for everyone in BXL starting Q3 2026 and adapted the tests task - 6331080
Updates to sales commission planning and reporting aim to make commission setup and achievement tracking clearer. This helps sales managers better monitor performance and manage commission plans with improved views and report behavior.
Odoo can now use official daily exchange rates from the Central Bank of Azerbaijan for automatic currency updates. This helps businesses using AZN translate foreign-currency accounting and tax transactions more accurately, including rates quoted for larger nominal amounts.
Original PR description
This commit adds the Central Bank of Azerbaijan (CBA) as a supported service provider for automatic currency rate updates. Purpose: To ensure multi-currency accounting entries and taxable transactions are accurately translated into the national currency (AZN) using the official exchange rate defined by the CBA for the transaction day. Functionality: -Enables fetching official daily exchange rates directly from CBA via XML. -Automatically handles rates defined for different nominal quantities (e.g., rates quoted per 100 units instead of 1 unit). Backport of: https://github.com/odoo/enterprise/pull/122626 task-6112867 Forward-Port-Of: odoo/enterprise#123436
Work order planning views now focus on planned work by default, reducing the chance of accidental replanning and keeping completed manufacturing dependencies out of planning charts. Shop floor card options now better match enabled settings, and engineering change cost comparisons are more accurate for operation changes.
The AI app now marks an upcoming retired Google embedding model as deprecated and automatically refreshes older embeddings that used deprecated models. This helps keep AI-powered features reliable without manual intervention when providers phase out older models.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
This pull request enhances the user experience for subcontracting workflows in Odoo. It simplifies the interface by renaming key columns and removing irrelevant fields, making it easier for users to manage subcontracting operations. These changes improve clarity and reduce potential confusion.
Original PR description
Small UX improvements for subcontracting, includes following changes: - Custom Operation Dependency should not be displayed/set if type of the BOM is subcontracting/kit. - Column name was changed from Free to use / On Hand subcontractor location to Subcontractor Stock - Manufacturing Readiness should not be displayed/set if type of the BOM is subcontracting/kit. task-6320074
This fixes Envia delivery failures for some Colombian cities whose postal codes were stored with fewer digits. The system now formats these codes correctly, helping shipments to and from affected locations such as Antioquia process more reliably.
Original PR description
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian…
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727 However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`). https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12 These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`. https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf ----- Ticket: opw-6248252 Forward-Port-Of: odoo/enterprise#123344 Forward-Port-Of: odoo/enterprise#120164
This fixes an issue where the cursor could jump backwards while typing in the Studio XML editor. The editor now keeps cursor position reliably per editing session, making report and view editing smoother and less disruptive for users.
Original PR description
Steps to reproduce the issue: -> Open studio -> Edit any view -> Edit xml => Cursor moves backwards when typing Some components inside of the report editor were managing the cursor position based on the document manually. Rendering timings could cause the cursor to move while typing. This commit internalizes the cursor position in the CodeEditor and keep track of them based on the sessionsId, making sure that the cursor position is always correct and only changing when switching between sessions while also making the component API simpler. Community: https://github.com/odoo/odoo/pull/274681
Employees and payroll teams can now access the payslip correction option directly from a payslip. This restores expected payroll workflow behavior and helps users correct payslip issues without needing to navigate elsewhere.
Original PR description
The payslip correction should also be available on the payslip. This is a backport of commit 117f0117a839cd29cb9f52aaf52b1e25efe1e314 task-6374294 Forward-Port-Of: odoo/enterprise#123558
The payroll pay run warning for missing payslips now works correctly again. This helps payroll teams catch incomplete pay runs before processing, reducing the risk of missed employee payments.
Original PR description
The missing payslip in a payrun warning wasn't triggered correctly because we were filtering on the schedule pay of the payrun and this field was removed in a previous PR. task-6329134 Forward-Port-Of: odoo/enterprise#121641
Fixed an issue where subscription product pages could fail when a discount was set directly on a recurring plan without a pricelist. Customers can now view the product page and see the correct discounted recurring price instead of an error.
Original PR description
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to…
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to reproduce:** 1. Create a subscription product with a recurring plan. 2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price). 3. Open the product page on the website. **Current behavior:** The page fails with a 500: Internal Server Error during price computation. **Expected behavior:** The page loads and shows the discounted recurring price. **Cause of the issue:** For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion. **Fix:** Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record. opw-6306105 Forward-Port-Of: odoo/enterprise#121466
This update corrects a bug where the Peppol demo mode wasn't correctly applied to databases that had previously been neutralized. Previously, the system defaulted to production mode, leading to incorrect document registration. This fix ensures the demo mode is properly set when installing Peppol on a neutralized database, preventing unintended data transmission to the live Peppol network.
Original PR description
When Peppol is installed on a database that was already neutralized (ex: a staging database where the feature is enabled after the neutralization happened), the account_peppol.edi.mode parameter is not set: data/neutralize.sql only runs at neutralization time, not when the module is installed afterwards. The demo/ data that also sets this parameter is not loaded on databases without demo data (real production/staging databases). As a result, _get_peppol_edi_mode() falls back to 'prod' and the neutralized database registers and sends documents against the live Peppol network. Steps to reproduce: - Neutralize a database on which Peppol is not installed yet - Install the account_peppol module - Open the Peppol settings / registration wizard: the mode is Production instead of Demo Force the demo mode in the pre_init_hook when the database is neutralized, mirroring data/neutralize.sql opw-6307710 Forward-Port-Of: odoo/odoo#275210 Forward-Port-Of: odoo/odoo#273019
This update fixes an issue where employees were incorrectly showing as having no remaining holiday days after being allocated time off. The fix ensures that the system accurately reflects available leave balances by correctly passing the target date through the calculation process, even when using sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update fixes an issue where the cursor position in the Odoo Code Editor would jump unexpectedly while typing. By internalizing the cursor tracking, the editor now accurately reflects the user's typing, providing a smoother and more reliable editing experience. This improves usability for developers working within Odoo.
Original PR description
Steps to reproduce the issue: -> Open studio -> Edit any view -> Edit xml => Cursor moves backwards when typing Some components inside of the report editor were managing the cursor position based on the document manually. Rendering timings could cause the cursor to move while typing. This commit internalizes the cursor position in the CodeEditor and keep track of them based on the sessionsId, making sure that the cursor position is always correct and only changing when switching between sessions while also making the component API simpler. Enterprise: https://github.com/odoo/enterprise/pull/123244
This update strengthens the website's wishlist feature by preventing unauthorized users from subscribing to products that don't exist or using existing user accounts. It now validates product availability and requires users to sign in before subscribing, reducing potential security risks and misuse of user data.
Original PR description
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This…
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts. Current behavior before PR: Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock). Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user. No validation is enforced, leading to potential security issues. Desired behavior after PR is merged: Adding a subscription for a non-existent or unavailable product raises a ValidationError. Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first. Backend validation prevents misuse of registered user emails and improves security. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275422 Forward-Port-Of: odoo/odoo#271880
A recent update to the website builder was causing slow updates due to a delay in fetching image sources. This fix resolves the issue by ensuring images have the correct source data, preventing performance bottlenecks and improving the builder's responsiveness. This impacts the user experience when editing website content.
Original PR description
Commit [1] introduced a cache for images' src in `_getValidSrc`. An undefined src will work but block the thread for a moment (up to seconds in some cases) until `fetch` returns a 404. The bug can be seen from the website builder: - Open the builder - Open your dev tools on the "network" tab - Click on the website logo => a failed fetch (404) appears and blocks the builder from being updated quickly. It happens because the element doesn't have any `dataset.originalSrc` (in this case, because it is an image field). [1]: https://github.com/odoo/odoo/commit/5164080cbadddaa7052dd4d2f997b944bd7a16e8 task-6247171 Forward-Port-Of: odoo/odoo#275078
This update fixes an issue where the ECPay payment portal displayed in simplified Chinese when Odoo was set to traditional Chinese. The fix ensures the portal correctly uses traditional Chinese (zh_TW) for users in Taiwan, aligning with the Odoo locale setting. This improves the user experience for our customers using the traditional Chinese language.
Original PR description
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in…
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal should show up in traditional Chinese (zh_TW) also. ## Steps to reproduce: In Odoo 19.0, 1. Install modules: payment_ecpay, website, ecommerce 2. Change the company and website language to Traditional Chinese (zh_TW). Make sure the currency is in TWD (Taiwanese Dollar) 3. Add ECPay as a payment method 4. Add some test products and checkout with ECPay 5. Observe the language on ECPay portal website, and payload in V5 package in network tab ## Cause of the issue: Initially the locale mapping was wrong, mapping CHI to zh. There's no "zh" locale, must either be "zh_TW" or "zh_CN". So when the Odoo locale is set to traditional Chinese (zh_TW), it included Language=CHI in the payload and redirect to ECPAY, making ECPay think that we're trying to request the simplified Chinese site. Caused by commit: 76c81d6f67b54940879b1020068c7140c4f2199b ## Fix: Fixed the language mapping following ECPay developer docs, and what language code to be included in the payload sent to ECPay from current Odoo locale. opw-6270820 --------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269206
This update resolves an issue where the 'ICE' field on customer records in the Odoo portal was not saving correctly. The change ensures that this critical field is properly updated, preventing it from remaining empty after customer modifications. This improves data accuracy and functionality for users.
Original PR description
After this PR https://github.com/odoo/odoo/pull/262274 ICE field on frontend was no longer saving on customer and because of that it always stays empty after save. Handle `additional_identifiers` field on portal to properly set those values in `additional_identifiers` fiels. task-5208254
This update fixes a discrepancy in the default tax date obligation for Serbian VAT invoices. Previously, the system defaulted to a 'By Issuance Date' setting, which wasn't compliant with Serbian law. Now, it correctly defaults to 'By Delivery Date' as mandated by Article 16 of the Serbian VAT Law, ensuring accurate tax reporting.
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273608