Módulo de Odoo en profundidad

1Instalar y conectar

Obtén blipit_monitor de apps.odoo.com o añade el repositorio a tu ruta de addons (en Odoo.sh como submódulo), actualiza la lista de aplicaciones e instala Blipit Error Monitoring. Odoo Online no permite módulos de terceros; Odoo.sh y los servidores propios sí. En Ajustes, Blipit, pega la clave secreta del proyecto (blipit_sk_...), marca 'Acepto los Términos del servicio de Blipit y la licencia del módulo' y Guardar. El módulo llama al endpoint activate con una huella de database.uuid y muestra 'Conectado a <project> (<org>)'. Rechaza una clave pública (403), una clave reemplazada (401) y una base de datos ya registrada en otro sitio (409), cada una con su motivo.

2Responsables

Cada empresa tiene Blipit: responsables. En un plan de una plaza la página de ajustes pide una sola persona que cubra todas las empresas; con más plazas y una sola empresa lista las personas de esa empresa; con varias empresas enlaza a Configuración, Responsables. Cada persona necesita un correo y acceso a la empresa, y recibe el grupo Blipit: ver incidencias reportadas. Cada cambio se envía a Blipit, que cuenta las personas distintas frente a las plazas del plan y rechaza una lista que añada personas por encima de ellas; Odoo entonces revierte el cambio y muestra el motivo. Las alertas de una incidencia nueva o una regresión van a los responsables de la empresa del evento; un evento sin empresa, o una empresa sin nadie, va a todos los responsables.

3Acceso multiempresa

Cada error de Python lleva la empresa actual como etiqueta y el SDK de navegador hace lo mismo. Blipit conserva las empresas vistas por incidencia y la sincronización las guarda. Una regla de registro muestra una incidencia a los usuarios con permiso en alguna de sus empresas; las incidencias sin empresa (acciones programadas, peticiones fuera de una empresa) son visibles para todos en el grupo Blipit.

4Regresiones en Odoo

La app Blipit lista las incidencias (sin resolver por defecto; agrupa por estado, tipo de excepción o release). Una incidencia que se corrigió y volvió lo indica en la parte superior y distingue los dos casos: en la misma release (la corrección probablemente nunca se desplegó) o en una release posterior (algo la reintrodujo). Filtros: Volvió tras una corrección, Corrección nunca desplegada. Resolver, Ignorar y Reabrir escriben de vuelta en Blipit; Abrir en Blipit salta al panel.

5Monitorización de inicios de sesión

Monitorizar inicios de sesión interactivos reporta los inicios fallidos, bloqueados y (si Reportar inicios de sesión correctos está marcado) correctos, con el usuario probado, la base de datos, la IP, el user agent y la hora; nunca la contraseña. Una instalación nueva tiene ambos marcados; una actualización desde una versión anterior los tiene desactivados hasta que un administrador los marca. Necesita el plan Scale: en otros planes la ingesta rechaza y el módulo se pausa durante diez minutos y lo registra una vez. La IP del cliente es correcta detrás de un proxy solo cuando Odoo se ejecuta con --proxy-mode.

6Sincronización y actualización

La acción programada Blipit: sincronizar incidencias se ejecuta cada diez minutos; Actualizar desde Blipit lo hace ahora. Las incidencias eliminadas en el lado de Blipit se quitan de Odoo. La lista de responsables se reenvía en cada sincronización para que un correo cambiado llegue a Blipit en diez minutos. El plan y la clave pública se releen de Blipit como máximo cada diez minutos por el emisor en segundo plano, nunca en una petición ni en la ruta de inicio de sesión.

Conviene saber

• Copias restauradas: una copia de producción lleva el database.uuid de producción y se rechaza con 409 'this database is already reporting to a different Blipit project'. Dale a la copia un database.uuid nuevo (Ajustes, Técnico, Parámetros del sistema) y conéctala a su propio proyecto con su propia clave. Staging y producción siempre deberían ser dos proyectos.
• Los errores se envían desde un hilo en segundo plano a través de una cola de 100 eventos; una tormenta descarta el resto con un aviso, y una petición nunca se ralentiza ni falla por culpa de Blipit. UserError y AccessError no se envían porque Odoo los registra sin traceback.
• Qué sale de Odoo: errores, la URL de la petición sin su query string, el id y el login del usuario, la empresa y los intentos de inicio de sesión que actives. Las contraseñas, los tokens de sesión y los cuerpos de petición nunca salen. La clave secreta nunca llega a un navegador.
• Los frames bajo el código propio de Odoo y site-packages se marcan como frames de biblioteca, así que la agrupación y los commits sospechosos se centran en tus módulos.
• Historial de versiones: blipit.io/changelog. Soporte: support@blipit.io.