Introduction

Odoo is a powerful, open-source business application platform that allows businesses to manage all aspects of their operations, including sales, purchases, inventory, accounting, and more. The core of any Odoo module is its business models and the relationships between them.  

These models consist of fields that can be broadly categorized into Basic (or Scalar) fields and Relational fields. Basic fields store simple data types such as integers, text, or dates, while Relational fields represent relationships between different models, like Many2one, One2many, or Many2many fields. 

In some scenarios, we may need to link the value of one field to another or have the value of a field dynamically calculated based on other fields. This is where Computed fields and Onchange fields come into play in Odoo. These two features allow for automation and dynamic updates of field values. This blog will explore the differences between Computed and Onchange fields, how to implement them, and when to use each in Odoo. 

Computed fields 

A Computed field in Odoo is a field whose value is not directly entered by the user but is instead calculated automatically using a method. This method computes the value based on the values of other fields in the model. The value of a computed field is not stored in the database; it is calculated each time the field is accessed, making it highly dynamic and suitable for calculations or data that should always be up to date. 

Let’s consider a scenario in which we have an Invoice model, and we want to calculate the total amount of an invoice based on its line items (e.g., products, quantity, and price). Below is an example of how a computed field can be used to calculate the total amount of the invoice: 

Example: Calculating Total Amount on an Invoice 

In this example, the total_amount field is computed by summing the subtotal of each invoice line. This ensures that the total_amount is always in sync with the individual line totals, and the computed value is updated automatically whenever the invoice lines change. 

Using @api.depends Decorator 

To ensure that the computed field is recalculated whenever the dependent fields change, we use the @api.depends decorator. This decorator specifies the fields that the computed method depends on. Whenever any of these fields change, the computed method is triggered to recalculate the value of the computed field. 

In this version, we are explicitly telling Odoo to recalculate the total_amount whenever any of the subtotal fields in the line_ids (invoice lines) change. Dependency ensures that the computed value reflects the latest changes. 

Using Functions in @api.depends 

Sometimes, we might want to compute dependencies dynamically, such as when the dependencies are determined by a function. Here’s an example: 

In this example, the get_dependencies function returns the fields that should be considered as dependencies for the computed field. The @api.depends decorator then dynamically uses this function to track dependencies. 

Onchange Fields 

The Onchange decorator in Odoo is used to trigger a method whenever the value of a specified field is modified. Unlike computed fields, Onchange fields are specifically triggered in the form view when a user updates a field’s value. The onchange mechanism is useful for making immediate updates to other fields based on a user’s input in the form, without the need to save the record to the database. 

For example, imagine you want to automatically update the order reference based on the customer name when a user selects a customer for an order. Here’s how you can achieve that using the onchange decorator: 

Example: Updating Order Reference Based on Customer Selection 

In this case, whenever the user selects a customer in the form, the order_reference field will automatically be updated to reflect the customer’s name, prefixed with “SO-“. The onchange method is triggered only when the customer_id field is modified in the form view. 

Key Points about onchange: 

1. Triggered by User Input: The onchange method is only triggered when a field is modified by the user in the form view. 

2. No Database Save Required: The changes made by the onchange method are not saved to the database until the record is explicitly saved. This means onchange is useful for client-side interactions without impacting the database. 

3. Non-blocking Logic: You can use onchange to display error messages, warn the user about invalid inputs, or even reset fields based on user input. 

Differences Between Compute and Onchange Fields 

Now that we’ve explored the functionality of Computed and Onchange fields, let’s compare their characteristics to better understand when to use each type. 

1. Trigger Mechanism: 

• Computed Fields: Computed fields are triggered every time they are accessed, whether in views or via code. For example, when the computed field is displayed in the form or tree view, the method to calculate its value will be triggered. 
• Onchange Fields: Onchange methods are triggered only when a user modifies a field in the form view. They do not trigger programmatically or in other views unless the user actively changes the field. 

2. Field Storage: 

• Computed Fields: The value of a computed field is not stored (can be stored with specific option) in the database; it is calculated dynamically when needed. 
• Onchange Fields: Onchange methods affect the UI in real time but do not store values in the database until the record is saved. 

3. Use Cases: 

• Computed Fields: Best used for calculations, summaries, or any dynamic data that should always be up to date, such as total prices, taxes, or other derived fields. 
• Onchange Fields: Ideal for making real-time changes to the form based on user input, such as updating related fields, showing error messages, or modifying the form view without saving the data. 

4. Performance: 

• Computed Fields: These fields are recalculated every time they are accessed, which can impact performance if they are accessed frequently or if there are many dependencies. 
• Onchange Fields: Only triggered when a specific field is modified, so they are more efficient in terms of performance as they only execute on user input. 

5. Debugging: 

• Computed Fields: Easier to debug because the computed function is clearly defined in the model, and you can trace the computation logic. 
• Onchange Fields: Debugging can be more challenging, especially when multiple onchange methods affect the same fields, making it harder to trace the origin of a value. 

6. Error Handling: 

• Computed Fields: Since the computed field’s value is always calculated, it doesn’t usually involve user input, so error handling is typically focused on ensuring the calculation logic is correct. 
• Onchange Fields: Onchange can return error messages or warnings based on user input, which allows for immediate feedback during form filling. 

Conclusion  

Computed fields ensure real-time calculations, while Onchange fields provide instant UI updates without saving to the database. Using Computed for backend automation and Onchange for interactive form behavior enhances performance and user experience in Odoo. However, implementing these correctly can be complex—zen8labs can help streamline your Odoo development with expert solutions tailored to your business needs. 

Duong Phi, Python Developer