Forem: Borovlev Artem

Beyond the Syntax: How onchange, depends and inverse Really Work in Odoo

Borovlev Artem — Sun, 01 Mar 2026 08:59:29 +0000

The Problem

Ask any Odoo developer to explain the difference between @api.depends and @api.onchange, and you'll get some version of the same answer:

"onchange is for the UI - it fires when the user changes a field in the form. depends is for computed fields - it runs when you save."

It's not wrong. But it's incomplete in ways that matter. And that incompleteness quietly causes bugs, unnecessary code, wasted debugging hours, and team arguments about why something "sometimes works and sometimes doesn't."

Here's what that incomplete understanding looks like in practice: a developer notices that a computed field isn't updating in the form view, so they add @api.onchange on top of @api.depends. It works. They ship it. Nobody questions it. Six months later someone else looks at that code and wonders: do we need both? what does each one actually do here?

Or a developer implements two fields that should stay in sync - change one, the other updates automatically. They set up compute and inverse. It works on save. But in the form view, it doesn't update until after saving. They're confused: isn't inverse supposed to handle this?

These aren't edge cases. They come up regularly, and they come up because the standard explanation - "onchange is UI, depends is on save" - doesn't tell you what's actually happening inside Odoo's ORM.

This article does.

Note: This research is based on Odoo 17 source code. The core mechanics described here apply equally to Odoo 16 and 18 - the underlying architecture hasn't changed.

The Interview Answer (And Why It's Not Enough)

The standard explanation maps roughly to this mental model:

User changes field in form
        ↓
   @api.onchange fires   ← "UI stuff"
        ↓
   User clicks Save
        ↓
   @api.depends fires    ← "DB stuff"

This model isn't completely wrong - it just describes what happens, not how or why. And once you start doing anything beyond the basics, the "what" stops being enough.

Consider these questions that the standard answer can't address:

If @api.depends only fires on save, why does a computed field sometimes update in the form view before saving?
If you have @api.depends and @api.onchange on the same method, are they doing the same thing? Different things? Is one redundant?
Why does inverse work perfectly when you call write() in code, but nothing happens when the user edits the field in the form?
Why does removing @api.onchange from a computed field sometimes break the UI - and sometimes change nothing at all?

To answer these, you need to understand what actually happens when a user changes a field value in an Odoo form. Not conceptually - mechanically.

Let's go through it.

What Actually Happens When a User Changes a Field

When a user modifies a field value in an Odoo form view, the browser sends an RPC call to the server - specifically to the onchange() method in web/models/models.py. What happens inside that method is more nuanced than it appears.

Here's the high-level sequence:

1. flush_all()                   - clear any pending computations from before
2. record = self.new(values)     - create a virtual record (no database ID)
3. snapshot0                     - capture the initial state of all fields
4. _update_cache(changed_values) - apply the user's change to the virtual record
5. modified(changed_fields)      - register which fields need recomputation
6. @api.onchange loop            - the real action happens here (see below)
7. snapshot1                     - capture the final state of all fields
8. diff(snapshot0, snapshot1)    - return only what changed to the browser

First, an important detail: the record has no database ID.

Odoo creates a virtual record - called a NewId record - to process the onchange. It exists only in memory. Nothing is written to the database at this point. This isn't a minor implementation detail - it's fundamental to understanding why certain things behave differently in onchange vs. write/create. We'll come back to this.

Now, step 5: what does modified() actually do?

modified() is an internal ORM method that most developers never call directly and rarely think about. When Odoo calls record.modified(changed_fields), it doesn't recompute anything. It simply walks the dependency graph - the relationships declared through @api.depends - and registers which computed fields are now outdated. Those fields get added to an internal queue called tocompute.

That's it. No computation. Just bookkeeping.

The real action is in step 6 - the onchange loop.

After modified() runs, Odoo enters a loop that processes @api.onchange methods for each changed field. But the interesting part isn't the onchange methods themselves - it's what happens between iterations.

After each onchange method runs, Odoo needs to figure out: did anything else change as a result? To do that, it reads the current value of every field in the form spec and compares it to the snapshot. And here's the key: reading a field triggers __get__().

__get__() is Python's descriptor protocol - it's called whenever you access an attribute on an object. Odoo's field implementation hooks into this. Inside __get__(), before returning a value, Odoo checks: is this field in the tocompute queue? If yes - compute it now.

So the actual execution of your @api.depends method happens here, inside the loop, triggered by reading the field to check if it changed:

onchange method runs for field_x
    ↓
Odoo checks: what else changed?
    ↓
reads field_y value  →  __get__()  →  field_y is in tocompute?
    ↓
YES  →  your @api.depends method runs right here
    ↓
field_y now has new value  →  it changed  →  added to next loop iteration

This cascading behavior is what makes the onchange system reactive. A user changes one field, an onchange method updates a second field, @api.depends recomputes a third - and all of this happens in a single RPC call, before any data touches the database.

snapshot1 in step 7 is just the final read of all fields after the loop completes. By that point, everything that needed computing has already been computed.

So: @api.depends does not fire "on save" as a standalone event. The method runs when the field is read (lazy evaluation via __get__()), or when a flush occurs - which is what actually writes computed values to the database. During onchange, the read happens inside the loop. Outside of onchange, recomputation happens when the field is read or when a flush is called - for example at the end of a transaction.

The "on save" mental model collapses two separate things into one: the moment the compute method runs, and the moment the result reaches the database. They're not the same event.

Where inverse Fits In - And When It Doesn't

inverse is Odoo's mechanism for making a computed field writable. When you define a computed field with an inverse method, you're telling Odoo: "if someone writes to this field directly, here's what to do with that value."

amount_currency = fields.Monetary(
    compute='_compute_amount_currency',
    inverse='_inverse_amount_currency',
    store=True,
)

def _inverse_amount_currency(self):
    for line in self:
        # env.is_protected() checks whether the field is currently being
        # recomputed by the ORM - a safeguard to prevent circular updates
        # when inverse and compute methods interact with each other.
        if not self.env.is_protected(self._fields['balance'], line):
            line.balance = line.amount_currency / line.currency_rate

inverse has exactly two entry points in the ORM: write() and create(). That's it. There is no other place in the framework where inverse methods are called.

This means: when a user changes a field in the form view and the onchange RPC fires - inverse is never involved. onchange doesn't go through write(). It works directly with the record cache via _update_cache(). The entire onchange pipeline - applying changes, triggering dependencies, running handlers - happens without touching write() at all.

So if you're expecting an inverse method to fire because a user edited a field in the UI, that expectation is wrong by design. inverse is a persistence mechanism. It runs when data is being committed - not when a user is still filling out a form.

There's another layer to this. Remember that onchange works on a NewId record - a virtual record with no database ID. Even if you somehow called write() manually inside an onchange handler, write() filters records before calling inverse:

real_recs = self.filtered('id')  # NewId records are excluded here

The filter exists because write() can be called in contexts where both real and virtual records are mixed. It's a safeguard, not a limitation.

The practical consequence: inverse handles the database side of a field. For anything that needs to happen in the UI before saving, you need a different tool - which is what the next section covers.

The Right Tools for the Right Job

Now that we understand how each mechanism works, the choice between them becomes clearer.

@api.depends declares a computational relationship between fields. It tells Odoo: when these source fields change, mark this computed field as outdated. The actual recomputation happens later - when something reads the field. In the context of onchange, that means the field updates in the UI only if Odoo reads it during the onchange pipeline (which happens when the field is part of the form's field spec). But @api.depends itself is not a UI mechanism - it's a dependency declaration. Without something triggering a read, the computed value stays stale until the next database flush.

@api.onchange is an event handler that the framework calls automatically when a user changes a field in the form view. The key word is automatically - Odoo's onchange pipeline picks up these methods and runs them. You can call them manually from code too, and they'll work fine. But the framework won't call them for you outside of a UI context. Use @api.onchange for things that are inherently about the editing experience: showing warnings, setting default values, recalculating fields, or any other logic that should react to user input in the form.

inverse is a persistence mechanism. Use it when a computed field needs to be writable and changing it should propagate back to the source data - but only at save time, only for records with real database IDs.

A practical way to think about it:

	Triggered by	Updates UI before save
`@api.depends`	read (lazily, after field is marked outdated)	✗
`@api.onchange`	onchange RPC (user edits in form)	✓
`inverse`	write / create	✗

Beyond the trigger: how these methods actually behave differently.

Understanding when each method fires is only part of the picture. They also behave differently in terms of what they receive and what they can return.

When @api.onchange is triggered from the UI, self is always a recordset of exactly one record - the one the user is editing. In @api.depends, self can be a batch of multiple records, which is why you always iterate with for record in self. In onchange that loop still works fine, but it's good to know the guarantee is there.

More importantly: @api.depends methods don't return anything. They compute a value and assign it directly to the field. That's the entire contract.

@api.onchange methods can optionally return a dictionary. In Odoo 17, the framework processes two keys from that return value:

return {
    "value": {"field_name": new_value, ...},  # assign field values
    "warning": {
        "title": "Something to note",
        "message": "Details here",
        "type": "dialog",  # or "notification"
    }
}

value lets you set other field values from inside the method - though assigning directly via self.field = value does the same thing and is more common. warning shows a dialog or notification to the user. Both keys are optional, and returning nothing at all is perfectly valid.

This return structure is unique to @api.onchange. There's no equivalent in @api.depends - computed fields communicate their result by assigning to self, not by returning.

On the double decorator question.

You'll sometimes see code like this:

@api.depends('partner_id')
@api.onchange('partner_id')
def _compute_payment_term(self):
    for record in self:
        record.payment_term_id = record.partner_id.property_payment_term_id

This isn't always wrong - but it's worth asking: why are both decorators here?

@api.depends already causes this method to run during onchange, via the tocompute → __get__() mechanism we described. Adding @api.onchange on top means the method runs twice during an onchange RPC: once triggered by @api.depends through the dependency system, and once explicitly by the onchange loop. In most cases, one of them is redundant.

The legitimate reason to have both is when you need @api.onchange specifically - to show a warning or handle UI-specific logic alongside a computed field. In that case, keep them as two separate methods: one decorated with @api.depends for the computation, one with @api.onchange for the UI side effects. Technically you can combine them, and it will work - but a method that both computes a field value and returns a warning is doing two different things. That makes it harder to read, harder to override in a subclass, and harder to reason about.

If you can't articulate why both decorators are needed on the same method, one of them probably shouldn't be there.

When things interact: a real example.

The clearest illustration of all three mechanisms working (and conflicting) together is bidirectional computed fields - where two fields each depend on the other, and changing either one should update the other in both the UI and the database.

This is exactly the problem I ran into and wrote about previously. The solution requires understanding that @api.onchange handles the UI reactivity, inverse handles the database sync, @api.depends keeps computed values current, and context flags are needed to prevent infinite recomputation loops - because each mechanism operates in a different scope and none of them alone is sufficient.

If you want to see these mechanics applied to a concrete problem with rounding drift on top, that writeup is here.

Conclusion

The standard interview answer - "onchange is for the UI, depends is for save" - isn't wrong. But it describes symptoms, not causes. And when you're debugging unexpected behavior or designing a non-trivial field interaction, symptoms aren't enough.

What actually matters is understanding the machinery:

@api.depends declares a dependency. The framework marks dependent fields as outdated when inputs change, and recomputes them lazily - when something reads the field. In the onchange pipeline that happens inside the loop, not at save time.
@api.onchange is an event handler that the framework calls automatically from the UI. It receives a single record, can assign field values, and can return a warning. Nothing more is processed.
inverse is called exclusively from write() and create(). It never runs during onchange, because onchange doesn't go through those methods.

Once you understand this, a lot of previously confusing behavior becomes predictable. You know why a computed field updates in the form without saving. You know why inverse doesn't fire when a user edits a field. You know why adding @api.onchange on top of @api.depends sometimes changes nothing - and sometimes matters.

And when you see @api.depends and @api.onchange on the same method, you know the right question to ask: what exactly is each decorator doing here, and does this method need both?

If you found this useful, the mechanics described here are put to work in a concrete problem in my previous article on circular recomputation and rounding drift in Odoo.

Circular recomputation and rounding drift in Odoo

Borovlev Artem — Sun, 01 Mar 2026 08:51:45 +0000

The Real Problem

In ERP systems, it’s common to have two fields that represent the same value in different units — for example, a purchase price in company currency and the same price in USD.

Both fields are editable. Both must stay synchronized.

For simplicity, let’s assume the conversion logic looks like this:

purchase_price_usd = round(purchase_price / rate, 2)
purchase_price     = round(purchase_price_usd * rate, 2)

The formulas here are intentionally simplified.
In real systems you would use proper currency utilities, precision handling, and framework helpers.
The goal of this example is to demonstrate the recomputation problem, not currency implementation details.

Now consider a basic case:

rate = 3
user enters purchase_price = 10

The system calculates:

purchase_price_usd = round(10 / 3, 2) = 3.33
purchase_price     = round(3.33 * 3, 2) = 9.99

Now the original value changes from 10 to 9.99.

Mathematically, this is correct.
From a user perspective, it is not.

The user entered 10. The system should not silently rewrite it.

This is not a floating-point bug.
This is not a rounding bug.
This is a consequence of combining:

bidirectional field derivation
rounding
automatic recomputation

And this is where circular recomputation begins to break user intent.

Why It Happens: The Onchange Loop

In Odoo, editable forms rely heavily on onchange.

When a user modifies a field in the UI:

The frontend sends the changed value to the server.
Odoo creates a temporary record snapshot.
The modified field is marked as changed.
All related @api.onchange and @api.depends logic is executed.
If any additional fields change during that process, Odoo runs another pass.

This continues until no more fields are considered “changed”.

This behavior is correct and intentional. It ensures consistency across dependent fields.

However, in a bidirectional setup like:

purchase_price → updates purchase_price_usd
purchase_price_usd → updates purchase_price

the mechanism becomes symmetrical.

When the user changes purchase_price:

purchase_price_usd is recomputed
that recomputation modifies purchase_price
the system detects a change
another pass begins

Even if the difference is only a rounding adjustment, it is still considered a change.

The framework does not know which field represents the original user intent.

It only sees that values differ - and tries to synchronize them.

This is how circular recomputation emerges.

Rounding as the Hidden Amplifier

Circular recomputation alone is not always visible.

The real problem becomes obvious when rounding is involved.

In bidirectional transformations, we implicitly assume that:

f⁻¹(f(x)) = x

But once rounding is applied, this is no longer true.

With rounding to two decimal places:

round(round(x / rate, 2) * rate, 2) ≠ x

Even if the difference is only 0.01, the system detects it as a real change.

From the framework’s perspective:

the value is different
therefore it must be synchronized

From the user’s perspective:

the value they entered was rewritten

The rounding does not create the loop.
It makes the loop observable.

Without rounding, tiny floating-point differences might still exist, but they often remain invisible at the UI level.

With rounding, the drift becomes explicit - and user intent gets overridden.

This is where mathematical correctness collides with practical ERP behavior.

Why the Usual Approaches Don’t Solve It

It is entirely possible to implement bidirectional synchronization using @api.depends and inverse.

Many Odoo modules use context flags inside inverse methods to prevent recursive writes. At the database level, this approach works reliably.

The real limitation appears at the UI level.

compute + inverse ensures consistency when the record is written. But it does not guarantee immediate synchronization while the user is editing a form.

In the form view, updates happen through onchange.

When a field is modified:

Odoo builds a temporary snapshot of the record
marks the changed fields
executes related onchange and compute logic
checks which fields were modified
runs additional passes if necessary

All of this happens inside a single onchange execution cycle.

There is no new request.
There is no fresh evaluation context.
The same record snapshot is iteratively processed until no further changes are detected.

This is important.

If two fields update each other, and rounding produces even a small difference, the framework sees it as a real modification. The loop continues.

So while compute + inverse can keep values consistent at write time, they do not solve the UI-level circular recomputation problem.

To preserve user intent during form editing, direction must be controlled inside the onchange cycle itself.

Controlling Direction Inside the Onchange Cycle

The core insight is simple:

At any given moment, only one field represents user intent.

When a user edits purchase_price, that value must be treated as authoritative.

The synchronized field (purchase_price_usd) should be updated - but the original field must not be touched again during the same cycle.

And vice versa.

The problem is that the onchange loop treats both fields symmetrically. It only sees value differences and tries to keep them aligned.

So we need to break that symmetry.

The solution is not to disable recomputation.

The solution is to control direction.

In practice, this means:

Detect which field triggered the onchange.
Set a context flag indicating the direction of synchronization.
Prevent the reverse update during the same cycle.

Example (simplified):

def onchange(self, values, field_names, fields_spec):
    ctx = {}

    if "purchase_price" in field_names:
        ctx["skip_purchase_price_recompute"] = True

    if "purchase_price_usd" in field_names:
        ctx["skip_purchase_price_usd_recompute"] = True

    self = self.with_context(**ctx)
    return super().onchange(values, field_names, fields_spec)

And in the corresponding compute methods:

@api.depends("purchase_price")
def _compute_purchase_price_usd(self):
    if self.env.context.get("skip_purchase_price_usd_recompute"):
        return
    for record in self:
        record.purchase_price_usd = ...

This does not change the mathematical model. It changes the execution model.

Instead of letting both fields fight for dominance, we explicitly define which side is the source of truth for this specific user action.

The rounding still exists.
The formulas remain symmetrical.
But the recomputation is no longer circular.
User intent is preserved.

Conclusion

Bidirectional field synchronization combined with rounding inevitably breaks mathematical reversibility.

The framework is not wrong.
The formulas are not wrong.
The issue arises from treating both fields as equally authoritative during UI recomputation.

In Odoo’s onchange cycle, any detected difference triggers another evaluation pass. With rounding involved, even minimal deviations are treated as real changes.

The only reliable way to preserve user intent is to control direction explicitly.

At any given moment:

one field must be considered the source of truth
the other must be derived
and reverse recomputation must be suppressed within the same evaluation cycle.

This is not a workaround. It is an architectural constraint of bidirectional derived fields in UI-driven systems.

Reusable Dev Environment for Odoo using Dev Containers & Base Image

Borovlev Artem — Sat, 14 Feb 2026 15:13:14 +0000

Working on multiple Odoo projects, I often ran into the same problems — different library versions, different Python interpreters, and different PostgreSQL setups. If you only work with one Odoo version (say, Odoo 14), that’s not a big deal. But once you have to maintain Odoo 14, 15, 17, and 18 — each requiring its own Python and PostgreSQL — the environment setup quickly becomes a mess.

On top of that, onboarding new developers was painful. Explaining how to set up each project, which Python to use, which dependencies to install, and how to connect to the right database — all of that took time and nerves.

For development I use VS Code, because it lets me work with different technologies in one consistent interface. After reading about Dev Containers, I realized they could solve exactly these issues — reproducible environments, isolated dependencies, and simple onboarding.

So I built a two-repository system:

one for a reusable base Docker image,
and another for a developer project template using VS Code Dev Containers.

Together, they give me a single command to spin up a full Odoo environment — Odoo + Postgres + mounted code + debugger — ready to work.

In this article, I’ll explain the reasoning behind this setup, the structure of both repositories, and how you can use the same approach for your own projects.

Architecture overview

My setup is split into two repositories:

Base image repository (github.com/BorovlevAS/dev_odoo_base_docker) — builds a Docker image per Odoo version (for example, 17.0) with all system dependencies, Python, wkhtmltopdf, Node LTS, postgres client, and a non-root user, etc.
DevContainer template repository (github.com/BorovlevAS/odoo_devcontainer_template) — a project skeleton where everything lives under /workspace: Odoo sources, extra addons, configs, scripts, and the .devcontainer folder.

The environment runs inside Visual Studio Code using the official Dev Containers extension — it automatically builds the defined container, mounts the workspace, and connects your VS Code session into it.

One command, and the developer is ready to work.

Principle: build heavy once → reuse across many projects.

Why I didn’t use the official Odoo image

The official odoo/docker image is great for running containers in production, but it’s not ideal for day-to-day development. It hides too much under the hood — system libraries, Python environment, and even where Odoo itself is installed. When you need to debug or patch something, you quickly hit invisible walls.

So I built my own base image optimized for development. Here’s what it gives me:

Full control over environment — I choose the OS (Ubuntu/Debian), Python and Node versions, PostgreSQL client, wkhtmltopdf, and all required system libraries. No “magic” from upstream.
Unified dev experience — developer tools are pre-installed: bash-completion, git, sudo, pre-commit, nodejs, and linters. No more “just install this manually”.
Direct Odoo source debugging — the full Odoo source is mounted inside the container, so I can browse, patch, or set breakpoints directly in VS Code.
Multi-version setup — versions 14/15/16/17/18 share the same structure and principles; only the base tag changes.
Speed & caching — each image contains a pre-built virtualenv and cached Python wheels, so Dev Containers start up fast without re-installing gigabytes of dependencies.
Proper permissions — runs as a non-root user with correct UID/GID for VS Code volumes. No permission surprises.
Predictable folder structure — /workspace, /opt/odoo/venv, and /usr/local/lib/node_modules/ always follow the same layout, which makes it easy to pre-configure VS Code and extensions.

Base image: decisions & ingredients (Odoo 18 as an example)

The base image represents the infrastructure layer of the development environment.

Its responsibility is limited and explicit:

provide a stable OS base
install system-level dependencies
prepare a Python runtime with an isolated virtual environment
establish a predictable filesystem layout for mounted projects.

It does not contain application code or business logic. Projects consume this image; they do not shape it.

OS base

For the current setup, the image is built on top of ubuntu:noble.

A full Ubuntu base simplifies:

installing and maintaining system libraries
working with .deb packages
keeping the environment close to common Linux setups used by development teams.

Image size is not the primary concern here — stability and predictability are.

System-level dependencies

The image installs a fixed set of system packages that rarely change between projects:

compiler toolchain and build essentials
common runtime libraries
fonts and rendering-related packages
client tools for external services (e.g. databases)

Installing these dependencies once in the base image avoids repeating the same setup across multiple projects and repositories.

Python runtime and virtual environment

Python is treated as a runtime platform, not as a project-specific concern.

The image creates a dedicated virtual environment located at:

/opt/odoo/venv

The virtual environment is added to PATH, so all Python tools inside the container use it by default.

At this layer, the image installs:

base Python tooling (pip, setuptools, wheel)
development utilities (debugpy, pre-commit)
Python dependencies required by the application framework, pinned to a specific major version.

Application source code itself is not part of the image.

Developer tooling (Node.js)

Node.js is included solely to support developer tooling.

In practice, it is used to run formatting and automation tools such as Prettier and its plugins.

It is not part of the runtime stack and is not involved in application execution.

By placing these tools in the base image, formatting behavior becomes consistent across all environments without requiring per-project setup.

User and permissions model

The image ensures the presence of a non-root user with UID/GID 1000, matching typical host user IDs.

This avoids permission issues when project files are mounted into the container and allows developers to work without elevated privileges.

Filesystem conventions

The image establishes a convention that all project files are mounted under:

/workspace

The base image does not populate this directory. It only guarantees that the environment expects application code, configuration, and scripts to appear there at runtime.

What this layer intentionally excludes

The infrastructure image deliberately does not include:

application source code
custom extensions or plugins
environment-specific configuration.

This separation keeps the base image reusable and stable, while allowing projects to evolve independently.

Unified `/workspace` structure

On top of the base image, every project follows the same filesystem convention: all project-related files are mounted under a single directory — /workspace.

This is not an implementation detail; it is a design decision.

From the editor’s point of view, /workspace is the project. There are no secondary mounts, hidden paths, or split workspaces.

A typical layout looks like this:

/workspace
 ├── .devcontainer/
 ├── conf/
 ├── docker/
 ├── extra_addons/
 ├── odoo/
 └── scripts/

One workspace, one mental model

Using a single top-level directory simplifies several things at once:

the editor works with a single workspace root
relative paths in configuration files remain stable
debugging and navigation behave predictably.

There is no need to remember where the core framework lives, where custom code is mounted, or how paths are stitched together inside the container.

Clear separation of concerns

Each directory under /workspace has a narrow, explicit role:

.devcontainer/ Dev Container configuration: how the environment is started and integrated with VS Code.
conf/ Runtime configuration files (application config, database config, tooling config).
docker/ Docker Compose files and optional project-level Docker overrides.
extra_addons/ Project-specific extensions and custom modules.
odoo/ Application framework source code, tracked as a Git submodule.
scripts/ Helper scripts for common development tasks (initialization, updates, tests).

This structure keeps infrastructure, framework, and project code clearly separated, while still being visible in a single place.

Why the framework lives inside the workspace

Keeping the framework source code inside /workspace is intentional.

It allows developers to:

inspect and debug framework code
step through execution without jumping between unrelated paths
apply temporary patches when needed during development.

At the same time, the framework remains isolated from the base image and can be versioned, updated, or replaced at the project level.

Configuration stays explicit

Configuration files are part of the project repository and live under conf/.

Nothing is hidden inside the image, and no configuration is generated implicitly. What the application runs with is always visible and version-controlled.

This makes environments easier to reason about and easier to reproduce.

Why this matters in practice

A unified /workspace layout reduces friction in daily work:

fewer assumptions about paths
fewer “where does this file live?” moments
less editor and debugger configuration.

Developers can focus on code and behavior, not on reconstructing the environment in their heads.

Dev Containers as the entry point

The Dev Container is the entry point into the development environment.

It connects the infrastructure layer (base image + Docker Compose) with the developer’s editor and defines how the project is opened, initialized, and used on a daily basis.

The configuration lives in .devcontainer/devcontainer.json and describes three key things:

how containers are started
which service the editor attaches to
what should happen when the environment is created.

Docker Compose as the runtime definition

Instead of defining a single container, the Dev Container setup relies on Docker Compose.

This allows the development environment to be described as a small system rather than a standalone container:

an application container
a database container
optional supporting services.

The Dev Container configuration references existing Compose files rather than replacing them.
This keeps the runtime definition declarative and reusable outside of VS Code if needed.

Attaching the editor to a running service

The editor attaches directly to the application service defined in Docker Compose.

From the editor’s perspective:

/workspace becomes the workspace root
the container user is a non-root developer user
all tools run inside the container context.

There is no special “editor container” and no duplicated environment.

Environment initialization

When the container is created for the first time, a project-specific initialization script is executed.

Typical responsibilities at this stage include:

generating local environment files
preparing configuration defaults
performing lightweight sanity checks.

This step is intentionally kept explicit and script-driven.

Nothing happens implicitly, and nothing is hidden inside the image.

Editor integration

The Dev Container configuration also defines the editor-side environment:

required extensions
interpreter paths
formatting and tooling settings
port forwarding for local access.

These settings are part of the repository and shared by the team.

As a result, every developer opens the project with the same editor configuration and the same tooling behavior.

What a developer actually does

From a developer’s point of view, the workflow is reduced to:

Clone the repository
Open it in the editor
Reopen in container

At that point, the environment is fully operational:

containers are running
the workspace is mounted
tools are available
configuration is in place.

The Dev Container does not add new concepts; it formalizes and automates existing ones.

Day-to-day developer workflow

Once the environment is up and running, daily development happens entirely inside the container.

There is no distinction between “local” and “container” workflows — the container is the development environment.

Running the application

The application is started directly from the editor using a predefined launch configuration.

This allows:

running the server in a controlled way
attaching the debugger immediately
restarting the process without rebuilding containers.

From the developer’s perspective, this feels no different from working in a local virtual environment — except the environment is fully reproducible.

Working with code

All code lives under /workspace and is immediately visible to the editor.

Typical tasks include:

implementing features in extra_addons/
inspecting or temporarily adjusting framework code under odoo/
navigating configuration in conf/.

There is no need to switch contexts or open multiple folders.
Everything relevant to development is available in a single workspace.

Updating the database and modules

Common repetitive tasks are handled through project scripts.

Updating modules or applying changes to the database is done via explicit commands rather than ad-hoc shell invocations. This keeps workflows consistent and reduces accidental mistakes.

Scripts are version-controlled alongside the project, making behavior transparent and reviewable.

Debugging

Debugging is one of the main reasons for keeping everything inside the same workspace.

Breakpoints can be set:

in project code
in framework code
across multiple modules.

Because the editor, runtime, and source code all live in the same environment, stepping through execution is predictable and stable.

Running tests

Tests are executed inside the same container and against the same environment used for development.

This avoids the common situation where:

tests pass locally but fail elsewhere
behavior differs due to mismatched dependencies.

No hidden state

All state that matters is either:

in version-controlled files
or in explicitly managed volumes.

Restarting containers does not break the workflow, and rebuilding the environment does not require manual reconfiguration.

The environment is designed to be disposable, not fragile.

Trade-offs and scope

This setup is intentionally opinionated.

It optimizes for development experience, reproducibility, and onboarding speed, not for minimalism or production deployment.

A few important boundaries to be aware of:

This environment is meant for development, not production. Security hardening, resource tuning, and deployment concerns are deliberately out of scope.
Docker Compose is used as a pragmatic runtime definition.This is not a Kubernetes-first setup and does not try to simulate production orchestration.
Images are not minimal. Stability, debuggability, and predictable tooling take priority over image size.
The approach assumes a long-lived codebase. For quick experiments or throwaway prototypes, this structure may be unnecessarily heavy.

These trade-offs are explicit.
The goal is not to cover every possible scenario, but to provide a reliable default for teams working on real projects over time.

Conclusion

This setup emerged from a practical need: working on multiple projects, across multiple Odoo versions, without constantly rebuilding development environments from scratch.

By separating concerns clearly:

a reusable infrastructure image
a consistent project layout under /workspace
and Dev Containers as the entry point

the development environment becomes predictable and disposable rather than fragile and stateful.

The biggest gain is not Docker itself, but consistency:

consistent tooling
consistent paths
consistent workflows.

Once established, the environment fades into the background and lets developers focus on code instead of setup.

Both repositories are intentionally simple and open to adaptation.
If this approach resonates with your workflow, feel free to reuse it, adjust it, or build your own variant on top of the same principles.

Forem: Borovlev Artem

Beyond the Syntax: How onchange, depends and inverse Really Work in Odoo

The Problem

The Interview Answer (And Why It's Not Enough)

What Actually Happens When a User Changes a Field

Where inverse Fits In - And When It Doesn't

The Right Tools for the Right Job

Conclusion

Circular recomputation and rounding drift in Odoo

The Real Problem

Why It Happens: The Onchange Loop

Rounding as the Hidden Amplifier

Why the Usual Approaches Don’t Solve It

Controlling Direction Inside the Onchange Cycle

Conclusion

Reusable Dev Environment for Odoo using Dev Containers & Base Image

Architecture overview

Why I didn’t use the official Odoo image

Base image: decisions & ingredients (Odoo 18 as an example)

OS base

System-level dependencies

Python runtime and virtual environment

Developer tooling (Node.js)

User and permissions model

Filesystem conventions

What this layer intentionally excludes

Unified /workspace structure

One workspace, one mental model

Clear separation of concerns

Why the framework lives inside the workspace

Configuration stays explicit

Why this matters in practice

Dev Containers as the entry point

Docker Compose as the runtime definition

Attaching the editor to a running service

Environment initialization

Editor integration

What a developer actually does

Day-to-day developer workflow

Running the application

Working with code

Updating the database and modules

Debugging

Running tests

No hidden state

Trade-offs and scope

Conclusion

Unified `/workspace` structure