...
Book Appointment

How to Make a Computed Field Editable in Odoo 19

A functional consultant configuring an editable computed field with an inverse method in Odoo 19 for odoo customization services.
  • Byte Legions
  • Odoo Technical

Computed fields are one of the most useful tools in Odoo, yet they carry a frustrating limitation the moment a real business process meets them: they are read-only by default. Your finance lead wants to type a margin directly. Your operations manager wants to override an auto-calculated delivery date. And the field just sits there, greyed out, refusing to cooperate. If you have ever tried to hand-edit an automatically calculated value and hit a wall, the fix is the inverse method, and the Odoo functional documentation treats it as the standard pattern for exactly this scenario.

This guide walks through how to make a computed field editable in Odoo 19 the right way: not by hacking the view, not by disabling automation, but by teaching the field how to reverse its own logic. We will cover the mechanics, a working implementation, the pitfalls that trip up even experienced teams, and the business decisions around when editability actually helps. If your team relies on solid Odoo functional documentation to keep customizations maintainable, this is the kind of pattern worth getting right the first time.

Why Editable Computed Fields Matter in Real Workflows

The value of an editable computed field is not technical elegance. It is workflow flexibility. Most calculated values in an ERP represent a default, not a law. A margin computed from cost and price is a suggestion until a sales manager negotiates a special deal. A commission calculated from a rate is accurate until an exception is approved. When users cannot override these numbers, they route around the system with spreadsheets, and that is where data integrity quietly falls apart.

Making a computed field editable gives you two-way field synchronization: the value calculates automatically when its inputs change, but a user can also type a number and have Odoo update the underlying inputs to match. You keep automation for the common case and human judgment for the exceptions, all inside one field. For business owners and ERP buyers evaluating how adaptable Odoo really is, this pattern is a strong signal. It means the platform bends to your process instead of forcing your process to bend to it.

The Core Mechanics Behind an Editable Computed Field

A computed field is defined by a compute method and, optionally, an @api.depends decorator that lists the fields it watches. By design, if a field only has a compute method, Odoo marks it read-only because there is nowhere for a user-entered value to go. To flip that behavior, you supply two additional ingredients.

Adding an Inverse Method to Your Field

The inverse parameter points to a method that does the opposite of your compute logic. Where the compute method reads dependencies and produces a value, the inverse method reads the manually entered value and updates the dependencies so the calculation stays consistent. Think of it less as a setter and more as a business logic hook that fires immediately after a user saves an override. Once you add the inverse attribute, Odoo stops treating the field as read-only and lets users type into it.

Why store=True Is Non-Negotiable Here

There is a detail that catches a lot of developers off guard. For the inverse method to fire reliably, the computed field needs store=True. A non-stored computed field is calculated on-the-fly and has no column in the database, so there is literally no place to hold a user-entered value long enough to process it. Adding store=True gives the field its own database column, enables searching directly on the field, and ensures the inverse method is triggered when someone edits the value. If your inverse method seems to be ignored, the missing store attribute is the first thing to check.

Step-by-Step: Making a Computed Field Editable in Odoo 19

Let us build a concrete example. Imagine a sales order line where discounted_price is normally computed from a unit price and a discount percentage, but you want power users to type a final price directly and have the discount back-calculated.

Defining the Compute Logic

Start with a stored computed field and its compute method. The @api.depends decorator tells Odoo which inputs should trigger recomputation.

python
from odoo import models, fields, api

class SaleOrderLine(models.Model):
    _inherit = 'sale.order.line'

    discount_percent = fields.Float(string="Discount (%)")

    discounted_price = fields.Float(
        string="Discounted Price",
        compute="_compute_discounted_price",
        inverse="_inverse_discounted_price",
        store=True, ) @api.depends('price_unit', 'discount_percent') def _compute_discounted_price(self): for line in self:
            line.discounted_price = line.price_unit * (1 - (line.discount_percent / 100))

Whenever price_unit or discount_percent changes, Odoo recalculates the discounted price automatically. That covers the standard direction of the workflow.

Writing the Inverse Function

Now add the method that runs the logic in reverse. When a user types a discounted price, this method figures out the discount percentage that would produce it and writes that back to the dependency.

python
 def _inverse_discounted_price(self): for line in self: if line.price_unit:
                line.discount_percent = 100 - ((line.discounted_price / line.price_unit) * 100)

That is the entire mechanism. The field now behaves both ways: change the discount and the price recalculates, or set the price directly and the discount adjusts to match.

Somewhere in the middle of a customization project like this, it pays to revisit the best practices for building custom modules in Odoo 19 so your compute and inverse logic stays clean, testable, and easy to upgrade later.

Handling Recomputation and Edge Cases

Two things deserve care here. First, guard against division and edge conditions, as the if line.price_unit: check above prevents a crash when the unit price is zero. Second, be intentional about the loop over self, because the inverse method receives a recordset and must iterate over every record rather than assuming a single one. If you skip that iteration, batch edits and imports will behave unpredictably. In Odoo 19 you should also confirm the field is genuinely editable in the form view, since a readonly Python expression in the view arch can still lock the field even when your model allows editing.

Common Pitfalls Functional Teams Run Into

The single most common error is the maximum recursion depth exceeded exception. This happens when your compute and inverse methods indirectly trigger each other in an endless loop, each one changing a value the other watches. Keep the two methods logically separated, and never let the inverse method write to a field that its own compute method depends on in a way that re-triggers the cycle.

The second pitfall is forgetting the view layer entirely. You can wire up the model perfectly and still see a greyed-out field because the form view forces it read-only. Remember that model-level editability and view-level editability are two different switches, and both need to agree. The third trap is treating a non-stored field as if it were stored. Without store=True, your inverse method quietly never fires, and the field silently reverts. Finally, be cautious with stored computed fields at scale, because every stored field adds a database write on recomputation, so weigh that cost when the field touches thousands of records.

When You Should and Shouldn't Make a Field Editable

Editability is a feature, not a default worth applying everywhere. Make a computed field editable when a value is a business default that legitimately needs human override: negotiated pricing, adjusted forecasts, manual date corrections, or approval-based exceptions. In those cases the inverse method turns a rigid calculation into a flexible, auditable input while preserving data integrity.

Avoid editability when the value should be a hard source of truth. Tax totals, system-generated sequence numbers, and audited financial figures should stay locked, because letting users overwrite them invites errors and compliance risk. The decision is functional before it is technical. If your team is weighing which fields deserve two-way behavior across a larger implementation, a short scoping conversation saves a lot of rework. Book a Odoo consultation with Byte Legions and we will map your editable fields to your real approval workflows before a single line of code is written.

Conclusion

Making a computed field editable in Odoo 19 comes down to three deliberate choices: add an inverse method, set store=True, and make sure the view actually allows editing. Get those right and you unlock a genuinely powerful pattern, where fields calculate themselves in the common case and gracefully accept human judgment in the exceptions. That balance between automation and control is exactly what separates a rigid ERP deployment from one that people actually enjoy using. Treat editability as a functional decision first, guard against recursion and view-level locks, and your custom fields will stay both flexible and trustworthy as your business scales.

Frequently Asked Questions

Do I always need store=True to make a computed field editable in Odoo 19?

In practice, yes. The inverse method depends on the field having a real database column so a user-entered value can be captured and processed. A non-stored field is computed on-the-fly with nowhere to hold the manual value, so the inverse logic will not fire reliably.

What causes the maximum recursion depth error with inverse methods?

It happens when your compute and inverse methods keep triggering each other in a loop, each one modifying a value the other watches. The fix is to keep the two directions of logic cleanly separated so an override does not re-trigger the same computation endlessly.

My field is editable in the model but still greyed out. Why?

The form view is almost certainly forcing it read-only. Model-level editability and view-level editability are separate controls in Odoo 19, and the view uses a readonly attribute evaluated as a Python expression. Check the view arch and make sure it is not locking the field.

Can an editable computed field still be searched and filtered?

Yes. Because you set store=True, the value lives in its own column, so Odoo can search and filter on it directly through the database. If you ever need to search a non-stored computed field, you would add a dedicated search method instead.

Is this better handled with Odoo Studio or a custom module?

For simple UI tweaks Studio is fine, but inverse logic is business code that benefits from version control, testing, and clean upgrades. A custom module is the more maintainable choice when you need reliable two-way synchronization and want your logic to survive future Odoo updates.

A functional consultant configuring an editable computed field with an inverse method in Odoo 19 for odoo customization services.
by Byte Legions0 CommentsOdoo Technical
A functional consultant configuring an editable computed field with an inverse method in Odoo 19 for odoo customization services.
  • Byte Legions
  • Odoo Technical

Computed fields are one of the most useful tools in Odoo, yet they carry a frustrating limitation the moment a real business process meets them: they are read-only by default. Your finance lead wants to type a margin directly. Your operations manager wants to override an auto-calculated delivery date. And the field just sits there, greyed out, refusing to cooperate. If you have ever tried to hand-edit an automatically calculated value and hit a wall, the fix is the inverse method, and the Odoo functional documentation treats it as the standard pattern for exactly this scenario.

This guide walks through how to make a computed field editable in Odoo 19 the right way: not by hacking the view, not by disabling automation, but by teaching the field how to reverse its own logic. We will cover the mechanics, a working implementation, the pitfalls that trip up even experienced teams, and the business decisions around when editability actually helps. If your team relies on solid Odoo functional documentation to keep customizations maintainable, this is the kind of pattern worth getting right the first time.

Why Editable Computed Fields Matter in Real Workflows

The value of an editable computed field is not technical elegance. It is workflow flexibility. Most calculated values in an ERP represent a default, not a law. A margin computed from cost and price is a suggestion until a sales manager negotiates a special deal. A commission calculated from a rate is accurate until an exception is approved. When users cannot override these numbers, they route around the system with spreadsheets, and that is where data integrity quietly falls apart.

Making a computed field editable gives you two-way field synchronization: the value calculates automatically when its inputs change, but a user can also type a number and have Odoo update the underlying inputs to match. You keep automation for the common case and human judgment for the exceptions, all inside one field. For business owners and ERP buyers evaluating how adaptable Odoo really is, this pattern is a strong signal. It means the platform bends to your process instead of forcing your process to bend to it.

The Core Mechanics Behind an Editable Computed Field

A computed field is defined by a compute method and, optionally, an @api.depends decorator that lists the fields it watches. By design, if a field only has a compute method, Odoo marks it read-only because there is nowhere for a user-entered value to go. To flip that behavior, you supply two additional ingredients.

Adding an Inverse Method to Your Field

The inverse parameter points to a method that does the opposite of your compute logic. Where the compute method reads dependencies and produces a value, the inverse method reads the manually entered value and updates the dependencies so the calculation stays consistent. Think of it less as a setter and more as a business logic hook that fires immediately after a user saves an override. Once you add the inverse attribute, Odoo stops treating the field as read-only and lets users type into it.

Why store=True Is Non-Negotiable Here

There is a detail that catches a lot of developers off guard. For the inverse method to fire reliably, the computed field needs store=True. A non-stored computed field is calculated on-the-fly and has no column in the database, so there is literally no place to hold a user-entered value long enough to process it. Adding store=True gives the field its own database column, enables searching directly on the field, and ensures the inverse method is triggered when someone edits the value. If your inverse method seems to be ignored, the missing store attribute is the first thing to check.

Step-by-Step: Making a Computed Field Editable in Odoo 19

Let us build a concrete example. Imagine a sales order line where discounted_price is normally computed from a unit price and a discount percentage, but you want power users to type a final price directly and have the discount back-calculated.

Defining the Compute Logic

Start with a stored computed field and its compute method. The @api.depends decorator tells Odoo which inputs should trigger recomputation.

python
from odoo import models, fields, api

class SaleOrderLine(models.Model):
    _inherit = 'sale.order.line'

    discount_percent = fields.Float(string="Discount (%)")

    discounted_price = fields.Float(
        string="Discounted Price",
        compute="_compute_discounted_price",
        inverse="_inverse_discounted_price",
        store=True, ) @api.depends('price_unit', 'discount_percent') def _compute_discounted_price(self): for line in self:
            line.discounted_price = line.price_unit * (1 - (line.discount_percent / 100))

Whenever price_unit or discount_percent changes, Odoo recalculates the discounted price automatically. That covers the standard direction of the workflow.

Writing the Inverse Function

Now add the method that runs the logic in reverse. When a user types a discounted price, this method figures out the discount percentage that would produce it and writes that back to the dependency.

python
 def _inverse_discounted_price(self): for line in self: if line.price_unit:
                line.discount_percent = 100 - ((line.discounted_price / line.price_unit) * 100)

That is the entire mechanism. The field now behaves both ways: change the discount and the price recalculates, or set the price directly and the discount adjusts to match.

Somewhere in the middle of a customization project like this, it pays to revisit the best practices for building custom modules in Odoo 19 so your compute and inverse logic stays clean, testable, and easy to upgrade later.

Handling Recomputation and Edge Cases

Two things deserve care here. First, guard against division and edge conditions, as the if line.price_unit: check above prevents a crash when the unit price is zero. Second, be intentional about the loop over self, because the inverse method receives a recordset and must iterate over every record rather than assuming a single one. If you skip that iteration, batch edits and imports will behave unpredictably. In Odoo 19 you should also confirm the field is genuinely editable in the form view, since a readonly Python expression in the view arch can still lock the field even when your model allows editing.

Common Pitfalls Functional Teams Run Into

The single most common error is the maximum recursion depth exceeded exception. This happens when your compute and inverse methods indirectly trigger each other in an endless loop, each one changing a value the other watches. Keep the two methods logically separated, and never let the inverse method write to a field that its own compute method depends on in a way that re-triggers the cycle.

The second pitfall is forgetting the view layer entirely. You can wire up the model perfectly and still see a greyed-out field because the form view forces it read-only. Remember that model-level editability and view-level editability are two different switches, and both need to agree. The third trap is treating a non-stored field as if it were stored. Without store=True, your inverse method quietly never fires, and the field silently reverts. Finally, be cautious with stored computed fields at scale, because every stored field adds a database write on recomputation, so weigh that cost when the field touches thousands of records.

When You Should and Shouldn't Make a Field Editable

Editability is a feature, not a default worth applying everywhere. Make a computed field editable when a value is a business default that legitimately needs human override: negotiated pricing, adjusted forecasts, manual date corrections, or approval-based exceptions. In those cases the inverse method turns a rigid calculation into a flexible, auditable input while preserving data integrity.

Avoid editability when the value should be a hard source of truth. Tax totals, system-generated sequence numbers, and audited financial figures should stay locked, because letting users overwrite them invites errors and compliance risk. The decision is functional before it is technical. If your team is weighing which fields deserve two-way behavior across a larger implementation, a short scoping conversation saves a lot of rework. Book a Odoo consultation with Byte Legions and we will map your editable fields to your real approval workflows before a single line of code is written.

Conclusion

Making a computed field editable in Odoo 19 comes down to three deliberate choices: add an inverse method, set store=True, and make sure the view actually allows editing. Get those right and you unlock a genuinely powerful pattern, where fields calculate themselves in the common case and gracefully accept human judgment in the exceptions. That balance between automation and control is exactly what separates a rigid ERP deployment from one that people actually enjoy using. Treat editability as a functional decision first, guard against recursion and view-level locks, and your custom fields will stay both flexible and trustworthy as your business scales.

Frequently Asked Questions

Do I always need store=True to make a computed field editable in Odoo 19?

In practice, yes. The inverse method depends on the field having a real database column so a user-entered value can be captured and processed. A non-stored field is computed on-the-fly with nowhere to hold the manual value, so the inverse logic will not fire reliably.

What causes the maximum recursion depth error with inverse methods?

It happens when your compute and inverse methods keep triggering each other in a loop, each one modifying a value the other watches. The fix is to keep the two directions of logic cleanly separated so an override does not re-trigger the same computation endlessly.

My field is editable in the model but still greyed out. Why?

The form view is almost certainly forcing it read-only. Model-level editability and view-level editability are separate controls in Odoo 19, and the view uses a readonly attribute evaluated as a Python expression. Check the view arch and make sure it is not locking the field.

Can an editable computed field still be searched and filtered?

Yes. Because you set store=True, the value lives in its own column, so Odoo can search and filter on it directly through the database. If you ever need to search a non-stored computed field, you would add a dedicated search method instead.

Is this better handled with Odoo Studio or a custom module?

For simple UI tweaks Studio is fine, but inverse logic is business code that benefits from version control, testing, and clean upgrades. A custom module is the more maintainable choice when you need reliable two-way synchronization and want your logic to survive future Odoo updates.

Comments are closed

Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.