Skip to content

Odoo Developer Mode Features and Debugging: Complete Reference

DeployMonkey Team · March 23, 2026 11 min read

Activating Developer Mode

Developer mode (debug mode) exposes technical features throughout the Odoo interface. There are three ways to activate it:

  • URL method: Add ?debug=1 to any Odoo URL (e.g., /web?debug=1)
  • Settings menu: Settings > General Settings > scroll to bottom > Activate Developer Mode
  • With assets: Use ?debug=assets to also load unminified JavaScript and CSS

The assets mode is essential for frontend debugging since it loads individual source files instead of bundled/minified versions, making browser DevTools useful.

Technical Menu

Developer mode reveals the Technical menu under Settings with access to:

  • Database Structure: Models, Fields, Constraints
  • User Interface: Views, Menus, Actions, Filters
  • Email: Templates, Servers, Mail Queue
  • Sequences & Identifiers: Sequences, External Identifiers
  • Actions: Server Actions, Automated Actions, Scheduled Actions
  • Security: Access Rights, Record Rules, Groups

Field Information Tooltip

With developer mode active, hovering over any field label shows a tooltip with technical information:

  • Field name (technical name used in code)
  • Field type (Char, Integer, Many2one, etc.)
  • Model name (the Python model)
  • Relation (for relational fields: the related model)
  • Whether the field is stored, required, readonly

This is invaluable for understanding existing Odoo modules without reading source code. You can quickly find the field name and model needed for customization.

View Inspector

The Edit View button (or the bug icon in the view toolbar) opens the view editor showing the XML architecture of the current view. You can see:

  • The view's XML ID and model
  • All inherited views and their priority/sequence
  • The combined/final XML after all inheritance

This helps debug view inheritance issues where your custom view extension is not appearing or appearing in the wrong location.

Action Inspector

In developer mode, every menu item and button shows its technical details. Click the bug icon next to the breadcrumb to see:

  • The action type (ir.actions.act_window, ir.actions.server, etc.)
  • The target model
  • Domain and context
  • View references

Access Rights Debugging

When users report access errors, developer mode helps diagnose them:

# In the Python shell or server log, you can see:
# Access denied for model 'sale.order' with operation 'write'
# because of security group 'Sales / User'

Use Settings > Technical > Security > Access Rights to view the ACL matrix. Check which groups have create/read/write/unlink on each model.

Record Rules Viewer

Settings > Technical > Security > Record Rules shows all domain-based access restrictions. Each rule has:

  • Model it applies to
  • Domain filter expression
  • Groups it applies to (empty = all users)
  • CRUD checkboxes

Toggle rules on/off to isolate access issues during debugging.

Automated Actions (Server Actions)

Settings > Technical > Automation > Automated Actions lets you create triggers without code:

# Example: Auto-assign tickets to a team lead
Trigger: On creation of support.ticket
Condition: [('priority', '=', '3')]
Action: Update record - user_id = ref('module.user_team_lead')

Automated actions can execute Python code, send emails, create activities, or update records. They fire on record create, write, delete, or on a timed condition.

Scheduled Actions (Cron Jobs)

Settings > Technical > Automation > Scheduled Actions shows all cron jobs. In developer mode, you can:

  • See the next execution date
  • Manually trigger a cron job by clicking Run Manually
  • Check the interval and number of calls
  • View the Python method being called

External Identifiers (XML IDs)

Settings > Technical > Sequences > External Identifiers maps XML IDs to database record IDs. This is essential for:

  • Finding the XML ID of any record: search by model and res_id
  • Debugging ref() calls in data XML files
  • Verifying that your module's data was loaded correctly

Shell Access

The Odoo shell provides a Python REPL with full ORM access:

$ odoo shell -d mydb
>>> env['res.partner'].search_count([])
42
>>> partner = env['res.partner'].browse(1)
>>> partner.name
'My Company'
>>> env.cr.execute('SELECT count(*) FROM res_partner')
>>> env.cr.fetchone()
(42,)

The shell is useful for testing ORM queries, inspecting data, and prototyping methods before writing them in modules.

Debugging Frontend Assets

With ?debug=assets, the browser DevTools become much more useful:

  • Individual JS files are loaded instead of bundles, so you can set breakpoints in specific files
  • CSS is unminified, making style inspection easier
  • Network tab shows individual asset requests, helping identify slow-loading resources

RPC Debugging

Odoo's web client communicates via JSON-RPC. In the browser Network tab, filter by /web/dataset/call_kw to see ORM calls. Each request shows the model, method, args, and kwargs being sent to the server.

PostgreSQL Query Logging

Enable SQL logging to see every query Odoo executes:

# In odoo.conf or command line:
--log-level=debug_sql

# Or for specific models only:
--log-handler=odoo.models:DEBUG

This reveals N+1 query problems, slow queries, and unexpected data access patterns.

Profiling with Odoo's Built-in Profiler

Odoo 15+ includes a built-in profiler accessible in developer mode. Click the clock icon in the top bar to start profiling. It records SQL queries, Python call stacks, and execution times for the current request.