Odoo · CLI · Debugging
Reiniciar el contenedor y pulsar F5 hasta que el error desaparezca no es una estrategia de depuración. odoo-bin trae un shell interactivo, un runner de tests con filtros finos y un sistema de logs configurable por logger: con media docena de comandos se diagnostica casi todo sin tocar el navegador.
Instalar y actualizar
-d, -i, -u y --stop-after-init
-d elige la base de datos, -i instala módulos y -u los actualiza (recarga Python, vuelve a cargar XML/CSV y ejecuta los scripts de migración si cambia la versión del manifest). Añadir --stop-after-init hace que el proceso termine en cuanto acaba de cargar, que es justo lo que quieres en un script o en CI: el código de salida te dice si fue bien.
# Actualizar un módulo y salir (útil en scripts y CI)
odoo-bin -c odoo.conf -d mi_bd -u mi_modulo --stop-after-init
# Varios módulos a la vez, separados por comas, sin espacios
odoo-bin -c odoo.conf -d mi_bd -u modulo_a,modulo_b --stop-after-init
# Desarrollo: recarga Python y XML al guardar, un solo proceso
odoo-bin -c odoo.conf -d mi_bd --dev=all --workers=0-u all no es una solución: actualiza cientos de módulos, tarda muchos minutos y puede sobrescribir datos que no están marcados como noupdate. Actualiza solo los módulos que has cambiado.
Shell
odoo-bin shell: el ORM en un REPL
El shell arranca Odoo sin servidor HTTP y te deja una variable env lista para usar como superusuario. Es la herramienta perfecta para reproducir un bug, inspeccionar datos o probar un dominio antes de escribirlo en una vista. La trampa: nada se guarda si no haces env.cr.commit(), y al salir la transacción se revierte.
$ odoo-bin shell -c odoo.conf -d mi_bd --no-http
>>> orders = env['sale.order'].search([('state', '=', 'draft')], limit=5)
>>> orders.mapped('amount_total')
[120.0, 89.5, 1500.0, 42.0, 310.0]
>>> # Probar como un usuario concreto (con sus ACL y record rules)
>>> user = env.ref('base.user_demo')
>>> env['sale.order'].with_user(user).search_count([])
12
>>> env.cr.rollback() # o env.cr.commit() si quieres persistirTambién puedes pasarle un script por la entrada estándar, lo que lo convierte en una alternativa limpia a los scripts XML-RPC para tareas puntuales de mantenimiento:
odoo-bin shell -c odoo.conf -d mi_bd --no-http < scripts/recalcular_totales.pyLogs
Subir el nivel de log solo donde hace falta
--log-level=debug inunda la consola. Es mucho más útil --log-handler, que ajusta el nivel por logger: puedes ver todas las queries SQL sin el resto del ruido, o solo los logs de tu módulo.
# Ver todas las queries SQL que ejecuta el ORM
odoo-bin -c odoo.conf -d mi_bd --log-handler=odoo.sql_db:DEBUG
# Solo tu módulo en DEBUG, el resto en INFO
odoo-bin -c odoo.conf -d mi_bd --log-handler=odoo.addons.mi_modulo:DEBUG
# Silenciar un logger ruidoso
odoo-bin -c odoo.conf -d mi_bd --log-handler=werkzeug:WARNINGVer las queries es la forma más rápida de detectar un N+1: si al abrir una lista aparecen cien SELECT casi idénticos, hay un bucle que lee registro a registro (ver performance en Odoo).
Tests y breakpoints
Ejecutar un solo test y pararse dentro
--test-tags acepta filtros por módulo, clase y método, así que no hace falta lanzar la suite entera para comprobar un arreglo. Combinado con --workers=0, un breakpoint() en el código te abre pdb en mitad del test.
# Todos los tests de un módulo
odoo-bin -c odoo.conf -d test_db -u mi_modulo --test-tags=/mi_modulo --stop-after-init
# Una clase concreta
... --test-tags=/mi_modulo:TestSaleBlock
# Un solo método
... --test-tags=/mi_modulo:TestSaleBlock.test_blocks_without_vat| Quiero… | Comando o flag |
|---|---|
| Aplicar cambios de XML/Python de un módulo | -u mi_modulo --stop-after-init |
| Recargar al guardar en desarrollo | --dev=all --workers=0 |
| Inspeccionar datos o reproducir un bug | odoo-bin shell -d mi_bd |
| Ver las queries SQL | --log-handler=odoo.sql_db:DEBUG |
| Ejecutar un test concreto | --test-tags=/modulo:Clase.metodo |
| Copia de producción segura para pruebas | odoo-bin neutralize -d copia_bd |
| Esqueleto de un módulo nuevo | odoo-bin scaffold nombre ruta/ |
neutralize conserva crons activos, servidores de correo y credenciales de pasarelas de pago. Tu entorno de pruebas puede acabar enviando emails a clientes reales.
Resumen
-u con --stop-after-init para actualizar, shell para inspeccionar (sin olvidar el commit), --log-handler para ver solo lo que importa y --test-tags con --workers=0 para depurar un test concreto. Y nunca pruebes sobre una copia de producción sin neutralizarla.