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=1to any Odoo URL (e.g.,/web?debug=1) - Settings menu: Settings > General Settings > scroll to bottom > Activate Developer Mode
- With assets: Use
?debug=assetsto 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.