Módulo Odoo em detalhes

1Instale e conecte

Obtenha o blipit_monitor em apps.odoo.com ou adicione o repositório ao seu addons path (no Odoo.sh como submódulo), atualize a lista de aplicativos e instale Blipit Error Monitoring. O Odoo Online não permite módulos de terceiros; o Odoo.sh e o on-premise permitem. Em Configurações, Blipit, cole a chave secreta do projeto (blipit_sk_...), marque 'I agree to the Blipit Terms of Service and the module licence' e Salvar. O módulo chama o endpoint activate com um fingerprint de database.uuid e mostra 'Connected to <project> (<org>)'. Ele recusa uma chave pública (403), uma chave substituída (401) e um banco de dados já registrado em outro lugar (409), cada um com o motivo.

2Responsáveis

Cada empresa tem Blipit: responsáveis. Em um plano de um assento, a página de configurações pede uma única pessoa que cobre todas as empresas; com mais assentos e uma empresa, lista as pessoas daquela empresa; com várias empresas, leva a Configuração, Responsáveis. Cada pessoa precisa de um e-mail e de acesso à empresa, e recebe o grupo Blipit: ver problemas reportados. Toda alteração é enviada ao Blipit, que conta as pessoas distintas em relação aos assentos do plano e recusa uma lista que adicione pessoas além deles; o Odoo então desfaz a alteração e mostra o motivo. Os alertas de novo problema ou regressão vão para os responsáveis da empresa do evento; um evento sem empresa, ou uma empresa sem ninguém, vai para todos os responsáveis.

3Acesso multiempresa

Todo erro de Python carrega a empresa atual como tag e o SDK de navegador faz o mesmo. O Blipit guarda as empresas vistas por problema e a sincronização as armazena. Uma regra de registro mostra um problema aos usuários permitidos em uma de suas empresas; problemas sem empresa (ações agendadas, requisições fora de uma empresa) são visíveis a todos no grupo Blipit.

4Regressões no Odoo

O app Blipit lista os problemas (não resolvidos por padrão; agrupe por status, tipo de exceção ou release). Um problema que foi corrigido e voltou informa isso no topo e distingue os dois casos: na mesma release (a correção provavelmente nunca foi publicada) ou em uma release posterior (algo o reintroduziu). Filtros: Voltou depois de uma correção, Correção nunca publicada. Resolver, Ignorar e Reabrir gravam de volta no Blipit; Abrir no Blipit leva ao painel.

5Monitoramento de login

Monitorar logins interativos reporta logins com falha, bloqueados e (se Reportar logins bem-sucedidos estiver marcado) bem-sucedidos, com o login tentado, banco de dados, IP, user agent e hora; nunca a senha. Uma instalação nova vem com ambos marcados; uma atualização de uma versão anterior os deixa desmarcados até que um administrador os marque. Exige o plano Scale: em outros planos a ingestão recusa e o módulo pausa por dez minutos e registra uma vez no log. O IP do cliente só está correto atrás de um proxy quando o Odoo roda com --proxy-mode.

6Sincronização e atualização

A ação agendada Blipit: sincronizar problemas roda a cada dez minutos; Atualizar do Blipit faz isso agora. Problemas excluídos no lado do Blipit são removidos do Odoo. A lista de responsáveis é reenviada a cada sincronização, então um e-mail alterado chega ao Blipit em até dez minutos. O plano e a chave pública são relidos do Blipit no máximo a cada dez minutos pelo remetente em segundo plano, nunca no caminho de uma requisição ou de um login.

Bom saber

• Cópias restauradas: uma cópia da produção carrega o database.uuid da produção e é recusada com 409 'this database is already reporting to a different Blipit project'. Dê à cópia um novo database.uuid (Configurações, Técnico, Parâmetros do sistema) e conecte-a ao seu próprio projeto com sua própria chave. Staging e produção devem ser sempre dois projetos.
• Os erros são enviados de uma thread em segundo plano por uma fila de 100 eventos; uma tempestade descarta o restante com um aviso, e uma requisição nunca é atrasada ou falha por causa do Blipit. UserError e AccessError não são enviados porque o Odoo os registra sem traceback.
• O que sai do Odoo: erros, a URL da requisição sem a query string, o id e o login do usuário, a empresa e as tentativas de login que você habilitar. Senhas, tokens de sessão e corpos de requisição nunca saem. A chave secreta nunca chega a um navegador.
• Frames dentro do código do próprio Odoo e de site-packages são marcados como frames de biblioteca, então o agrupamento e os commits suspeitos se concentram nos seus módulos.
• Histórico de versões: blipit.io/changelog. Suporte: support@blipit.io.