overview-of-what-developers-need-to-know-in-odoo-19-technical-changes.jpg

By: Arjun V P

Sep 25,2025

Overview of What Developers Need to Know in Odoo 19 Technical Changes

Functional Odoo 19 Odoo Enterprises Odoo Community

Odoo’s technical foundation continues to evolve with every release, bringing changes that streamline development, improve maintainability, and open new possibilities for customization. For developers, staying on top of these updates is essential—not only to keep custom modules compatible, but also to take advantage of the improvements that make the framework faster, cleaner, and easier to work with.

This blog highlights some of the key technical updates in Odoo 19 and explains why they matter from a developer’s perspective.

Core Foundation Updates

Python Version Requirement

Odoo 19 takes a step forward by requiring Python 3.10 or higher. This change is critical for developers, as older Python versions are no longer supported. Migrating ensures compatibility with the updated Odoo codebase and allows developers to leverage modern Python features and performance improvements.All custom modules must be checked to ensure they run correctly on this new minimum version, particularly for any reliance on deprecated language features or external libraries.

Port Configuration

In older versions of Odoo, the configuration file used xmlrpc_port for specifying the HTTP port (commonly 8069).

From Odoo 19 onwards, this has been renamed to http_port.

This change removes the older XML-RPC reference, aligning Odoo’s configuration with a more standardized naming convention.

Introducing any! Operator for Enhanced ORM Query Flexibility

Odoo’s ORM gains a powerful technical enhancement with the introduction of the any! and not any! operators. These internal operators enable developers to perform searches on related models while bypassing access rights and record rules, offering greater flexibility for server-side queries without compromising security, as their use is restricted from RPC calls. This change streamlines internal data processing for system-level tasks, such as generating reports or automating workflows, by allowing unrestricted queries across related records. For developers, this feature simplifies complex query logic and supports advanced use cases like AI-driven automation and compliance reporting, all while maintaining robust security controls through restricted access.

Simplified ORM Search with Unified _search Method

Odoo has streamlined its ORM by merging the responsibilities of _where_calc into the _search method, controlled through the active_test and bypass_access flags. This refinement reduces duplication in the query-building process and ensures that all domain evaluation, access rules, and active field logic are handled consistently from a single entry point. For developers, this brings greater clarity when customizing search behavior, as there is now only one method to extend or override. It also makes debugging easier and improves maintainability of custom modules, since search logic is centralized and more predictable, ultimately reducing the risk of issues during future upgrades.

Stock & Accounting

One of the biggest technical shifts in Odoo 19 is the removal of stock.valuation.layer. Inventory valuation is now stored directly on stock.move, following a well-defined priority system: manual values first, then bills or invoices, followed by purchase or sales orders, and finally standard price. A new product.value field logs manual updates, and developers can retrieve values at a specific date using context.

This refactor significantly simplifies valuation logic. Instead of replaying historical movements to reconstruct valuations, Odoo focuses on reflecting the current situation as accurately as possible. For developers, this means fewer edge cases to handle and easier alignment with accounting documents. However, it also means custom modules that relied on stock.valuation.Layer must be updated to use the new system. The trade-off is worth it: the model is cleaner, faster, and more consistent with real-world accounting practices.

Odoo MRP Revamp Boosts Flexibility

Odoo’s MRP and Inventory modules just got a major boost!

Model Replacement: The old procurement.group model is replaced with the new stock.reference, enhancing document linking flexibility.
MTO Improvement: This change reliably connects Sales Orders and Manufacturing Orders, significantly improving Make-to-Order (MTO) flows.
New Grouping: A new mrp.production.group model is introduced to organize Manufacturing Orders into backorders or parent-child structures, ensuring better tracking and visibility.

Point of Sale (POS)

The POS renderer service has been updated to be more stable and testable, providing direct benefits to developers:

Dedicated Unit Test: The service now includes a dedicated unit test, making the testing of POS frontend behavior more reliable.
External Export: The renderer can now be exported for external use, simplifying integration and extension efforts.
Developer Impact: Customizing the POS (e.g., displaying product lines or integrating payment widgets) is now simpler because you are working with a stable, testable renderer designed with extension in mind.

Hardware & IoT

Odoo 19 brings two key technical improvements to simplify IoT development and maintenance:

Standardized Networking: Networking inside IoT drivers is now standardized by replacing urllib3 with requests. This aligns the IoT code with the rest of Odoo's Python codebase, which reduces maintenance overhead and inconsistencies.
Simplified Local Testing: Odoo introduces a test IoT system that runs on Linux or macOS without actual hardware devices. This allows developers to simulate IoT flows (like barcode scanning or printer interactions) directly in a local setup, making testing easier and removing the dependency on physical devices.

Website & Template Engine

Odoo 19 introduces several key changes to improve front-end development and templating best practices:

Carousel API: The website carousel is improved to match Bootstrap's API, ensuring more predictable behavior and easier configuration.
Template Inheritance: A new inheritance mode = "inner" is introduced. This allows developers to replace only the inner content of a template while preserving its outer structure, which simplifies overriding and reduces rewriting issues.
Template Engine Migration: The deprecated t-esc attribute is completely migrated away in favor of the modern t-out.

Action Required: Custom modules relying on t-esc must be updated to align with the new standard, ensuring long-term support and cleaner templates.

Dashboards & Data Fetching

The spreadsheet dashboard received a refactor to centralize data fetching, offering developers greater flexibility:

Data Storage Shift: Previously, data was flattened before storage (limiting flexibility); now, full raw records are kept.
Developer Control: Developers can override the fetch method when needed.
Benefit: Allows templates to work directly with unflattened, raw data for custom calculations and visualizations, reducing duplicated logic and enabling tailored enterprise reporting solutions.

Web Hierarchy View

A subtle but practical improvement to the Web Hierarchy View enhances navigation for power users and developers:

New Navigation Method: Records can now be opened in a new tab or window using Ctrl+Click or middle-click.
Practical Benefit: Makes working with large hierarchies more efficient by allowing users to move between different parent-child levels without losing their current place (e.g., while debugging data structures).

XML & Search Views

Odoo 19 removes legacy attributes from search views as part of a cleanup effort, aiming for a more streamlined view system:

Removed Attributes: The attributes expand and string have been removed from group elements in search views.
Action Required: Developers must adjust custom XML definitions that still rely on these outdated attributes.
Benefit: This change improves consistency across views and reduces overall clutter in XML definitions.

Module Consolidation in account_edi_ubl_cii

Odoo 19 consolidates modules to streamline the Electronic Data Interchange (EDI) framework:

Module Merger: The account_edi_ubl_cii_tax_extension module has been merged into account_edi_ubl_cii.
Developer Benefit: This reduces module fragmentation, making upgrades smoother and maintenance easier.
Consistency: It keeps the electronic invoicing standards (UBL/CII) consistent within a single, simplified module

Simplifying Timezones with env.tz

The introduction of the env.tz feature significantly simplifies timezone management for developers:

Simplified API: It replaces complex, tricky timezone code with a single, easy-to-use method.
Accurate Time: Ensures accurate times across different applications (e.g., HR schedules, POS receipts, CRM meetings).
Code Cleanup: Applied across 15 files in the core codebase, cleaning up code and boosting reliability for developers building custom modules.

Odoo QWeb: Faster, Cleaner Templates

Odoo's QWeb templating engine receives key upgrades for smoother and more efficient template creation:

Modern t-call Syntax: The t-call feature now uses attributes (e.g.,<t t-call="my_template" custom="x + y"/>), replacing the older, messier t-set approach for cleaner templates.
Performance Boost: Lazy XML evaluation means template content only renders when needed, which boosts speed and improves handling of large templates.
Action Required: Developers will need to update custom templates to align with the new, cleaner syntax, resulting in a more powerful template engine.

HR Module Refactor

Odoo 19 restructured its HR and Recruitment functionality, resulting in the removal of two models:

Model Removed: The base model hr.employee.base (used in Odoo 18) has been removed.
Model Removed: The hr.candidate model has been dropped as recruitment logic was refactored.
Developer Action: Developers maintaining custom HR extensions must review their inheritance chains and update any dependencies to the new HR structures.
Benefit: This cleanup reduces redundancy, eliminates unnecessary layers, and better aligns the HR application with other Odoo business apps.

Kanban Layout Update

The old <t t-name="kanban-box"> layout has been replaced with <t t-name="card">.
This update is part of Odoo’s shift toward simpler, Bootstrap-friendly components.
Developers must update custom Kanban templates to match the new structure.
The change ensures a more consistent look and feel across Odoo applications.

Purchase & Sale Order Lines: Field Updates

In Odoo 19, the product_uom field has been replaced with product_uom_id in both Purchase and Sale Order Lines.
This change follows Odoo’s convention of using the _id suffix for relational fields, ensuring greater consistency across the ORM.
The taxes_id field in Purchase Order Lines has been renamed to tax_ids, now supporting multiple taxes per line.

Product UoM Object Field Cleanup

The category_id field has been removed from the Product UoM object. By eliminating unused fields, Odoo 19 reduces database clutter and improves maintainability. Custom modules that reference category_id will need adjustments, but the trade-off is a leaner and more consistent UoM model.

Website Sale Changes

Order Retrieval: The old sale_get_order() method has been replaced by request.cart. This simplifies cart management and ties it more directly to the HTTP request context.
Cart Creation: Similarly, _create_cart() replaces sale_get_order() for initializing carts. This makes the cart lifecycle more explicit and easier to control.

HR Expense & Expense Sheet Cleanup

Two major HR fields and models are removed in Odoo 19:

product_uom_category_id in HR Expense
hr.expense.sheet model

The functionality of grouping, submission, and approval has been consolidated and streamlined directly onto the existing individual expense model. Developers relying on these models or fields must refactor their modules accordingly.

JavaScript Services Update

Odoo controllers now prefer type="jsonrpc" over type="json". This brings better compatibility with Odoo’s RPC mechanism and unifies data handling between frontend and backend. Developers with custom controllers should update their routes to ensure compatibility

Security Groups: From category_id to privilege_id

In Odoo 18, security groups could be linked via category_id. In Odoo 19, this is replaced with privilege_id. This shift clarifies the purpose of group privileges and aligns better with Odoo’s access control model. Custom security rules and XML definitions referencing category_id will need to be updated.

Context Handling: self._context > self.env.context

The legacy self._context is officially replaced by self.env.context. While env.context has been available since earlier versions, Odoo 19 completes the transition, reinforcing env-based coding standards. Developers maintaining old modules should switch to env.context for consistency and upgrade safety.

Expression Import & Groups Field

The old from odoo.osv.expression import OR is deprecated. Instead, use Domain.OR for cleaner, standardized domain operations.
The users field is replaced by user_ids. XML and Python code referencing users must be migrated to the new naming.

Product & Accounting Fields Cleanup

The sale_line_warn field was removed in Odoo 19. Custom modules that relied on it must be revised to ensure proper sale order warnings.
In account.move.line, the product_uom_category_id field is removed. Customizations depending on it need to be restructured to rely on available UoM relations.

Account Account Fields Cleanup

Deprecated fields in account.account are removed in Odoo 19. Custom accounting logic relying on them must be adjusted.

Website Pricelist & Partner Field Updates

The field website.pricelist_id is replaced by request.pricelist. Update website/shop-related modules accordingly.
The mobile field is removed from res.partner. Use phone or other contact fields instead for compatibility.

SQL Constraints & API Returns

_sql_constraints is now replaced with models.Constraint. Developers must switch to the new constraint definition format.
The @api.returns decorator is removed. Developers should replace it with modern Odoo API patterns.

Fleet Vehicle, Sale & Purchase Updates

The field first_contract_date is replaced with contract_date_start in Fleet.

The field tax_id is replaced with tax_ids in Sale Order Lines (now supporting multiple taxes per line).

The notes field in Purchase Orders is renamed to note.

Portal Method

The function check_access_rights is replaced by check_access in Odoo 19. This simplifies access control handling in portal-related customizations.

Partner Field Updates

The field last_website_so_id (last sales order created by a partner via the website) is removed.

The picking_warn field is also removed from partners, requiring migration of any dependent logistics customizations.

POS Method

The method this.pos.get_order() is renamed to this.pos.getOrder(). Custom POS modules must adjust to the new camelCase standard.

Partner Title Model

The model res.partner.title is removed in Odoo 19. Modules referencing it must be updated or restructured.

Res Users Groups Field

The field groups_id is renamed to group_ids. Update security rule definitions and custom code accordingly.

Multi-Company Context Refinements

Access to multi-company environments has been streamlined with the standardized use of env.company and env.companies. Switching between companies is now more consistent and predictable, reducing edge cases that previously required workarounds. Developers working with company-dependent records should adapt their custom code to these refined APIs for a smoother experience.

Bringing it all together, Odoo 19 clearly goes beyond routine enhancements. With its refined ORM, template engine improvements, cleaner accounting, and simplified IoT handling, the framework is now more consistent and developer-friendly than ever. While some adjustments—like field renaming, removed models, or context handling changes—will require developers to adapt their custom modules, these shifts create a stronger and more maintainable foundation.

By aligning early with these updates, teams can minimize upgrade pain, ensure long-term compatibility, and take full advantage of Odoo’s evolving ecosystem. This release not only streamlines development but also sets the stage for faster, more reliable innovation across every Odoo deployment.

To read more about The Ultimate Guide to Odoo 19 New Features and Enhancements, refer to our blog The Ultimate Guide to Odoo 19 New Features and Enhancements.

FAQ Section

Which Python version is recommended for Odoo 19?

A: Odoo 19 requires Python 3.10 or higher. The recommended version is Python 3.12 for best performance and long-term support

What is the purpose of the new any! and not any! operators?

A: These internal operators are designed for server-side logic (like complex computed fields) that need to query related records while explicitly bypassing the standard access rights and record rules. They are used to implement core framework features and should not be exposed in domains passed via RPC (e.g., from the frontend)