Odoo 20 amplia o modo offline para que os usuários possam criar, editar, arquivar, desarquivar e excluir registros sem uma conexão ativa. As pesquisas executadas anteriormente também podem ser realizadas offline. Quando a conectividade retorna, filas de sincronização tratam as alterações, com uma interface offline e ferramentas de gerenciamento para monitorar o processo. (Notas de versão do Odoo 20; Odoo fica offline) Isso transfere o acesso offline de um recurso de visualização de contingência para um modo de trabalho que pode alterar dados de negócios. As organizações que avaliam o Odoo 20 devem examinar como essas alterações se comportam quando são sincronizadas, e não apenas se os registros permanecem acessíveis durante uma interrupção.

O Odoo Nightly lista o Odoo 20 como uma versão estável e recomendada da Community Edition, datada de setembro de 2026 e com suporte até o Odoo 23. (nightly.odoo.com) Essa सूचीagem é relevante para o planejamento da Community Edition, mas não estabelece cobertura offline idêntica em todas as plataformas, ambientes Enterprise ou bancos de dados personalizados. A cobertura deve ser verificada no ambiente de implantação pretendido.

O que mudou em relação ao Odoo 19

O modo offline do Odoo 19 permite que os usuários visualizem registros abertos antes da perda da conexão, mas não os modifiquem enquanto estão offline. O Odoo 20 adiciona criação, edição, arquivamento, desarquivamento e exclusão de registros. (Docs do Odoo 19.0: Modo Offline Geral; Notas de versão do Odoo 20) Trata-se de uma expansão funcional, e não de um novo nome para o cache anterior. No Odoo 19, os usuários podem se preparar para a desconexão abrindo os registros relevantes, mas o trabalho que altera esses registros deve aguardar a conectividade. O Odoo 20 oferece suporte tanto a novos registros quanto a alterações em registros existentes enquanto está offline. (Docs do Odoo 19.0: Modo Offline Geral; Notas de versão do Odoo 20)

As avaliações de versão devem distinguir o acesso a informações em cache da capacidade de concluir e enfileirar operações em registros. Um fluxo de trabalho que só exige dados de referência tem requisitos diferentes de outro que envolve entrada de dados, mudanças de status ou exclusão. (Docs do Odoo 19.0: Modo Offline Geral; Notas de versão do Odoo 20)

Operações offline confirmadas

As ações confirmadas do Odoo 20 abrangem cinco etapas do ciclo de vida do registro: criação, edição, arquivamento, desarquivamento e exclusão. As pesquisas executadas anteriormente também estão disponíveis enquanto offline. (Notas de versão do Odoo 20) Os testes de aceitação devem incluir pelo menos um cenário para cada ação e confirmar que o estado esperado do registro aparece após a reconexão e a sincronização.

A sessão Experience do Odoo descreve uma interface offline dedicada, filas de sincronização e ferramentas para monitorar e gerenciar a sincronização. (Odoo fica offline) Essas funções devem ser cobertas no treinamento de usuários e nos procedimentos operacionais. Os usuários precisam saber onde os itens enfileirados aparecem, como identificar um item não resolvido e quem o revisa. O material fornecido confirma que existem ferramentas de gerenciamento, mas não define o fluxo de trabalho completo nem as permissões administrativas.

É necessário verificar o cache e a cobertura de pesquisa

A documentação do Odoo 19 descreve o acesso offline em termos de registros abertos antes da perda de conectividade. O Odoo 20 confirma separadamente que pesquisas executadas anteriormente podem ser feitas offline. (Docs do Odoo 19.0: Modo Offline Geral; Notas de versão do Odoo 20) As fontes fornecidas não especificam quanto dado relacionado é mantido, por quanto tempo ele permanece disponível, se existem limites de armazenamento ou se todos os campos associados a um registro em cache ficam disponíveis. Elas também não estabelecem se repetir uma pesquisa offline retorna o conjunto original de resultados ou apenas os dados já armazenados no dispositivo.

Antes de aprovar um fluxo de trabalho offline, as equipes devem identificar as pesquisas e os tipos de registro necessários para cada função. Os testes devem começar online, executando as pesquisas relevantes e abrindo os registros necessários. Em seguida, os testadores podem desconectar e repetir as tarefas pretendidas, incluindo qualquer uso de anexos, registros vinculados e campos obrigatórios. Esses são pontos de verificação, não limitações confirmadas, porque as informações de lançamento fornecidas não descrevem seu comportamento. (Notas de versão do Odoo 20)

O tratamento de conflitos precisa ser testado

As filas de sincronização e as ferramentas de gerenciamento estão confirmadas, mas as fontes fornecidas não explicam como o Odoo 20 resolve alterações concorrentes no mesmo registro, falhas de validação após a reconexão ou dependências entre operações enfileiradas. (Odoo fica offline) A presença de uma fila não estabelece uma política de conflito. Seu comportamento deve ser demonstrado na versão e configuração pretendidas do Odoo.

Um teste de conflito pode ter um usuário alterando um registro offline enquanto outro altera o mesmo registro online. Após a reconexão, a equipe deve inspecionar os valores resultantes, o status da fila e a notificação ao usuário. Testes separados devem cobrir uma edição offline de um registro arquivado ou excluído em outro lugar, e um registro recém-criado que falha em uma regra do servidor. Os testes devem documentar se uma atualização prevalece, se ocorre uma mesclagem ou se é necessária intervenção manual. (Odoo fica offline)

Controles de acesso e ações destrutivas

Como o Odoo 20 inclui arquivamento, desarquivamento e exclusão offline, a avaliação deve ir além da entrada rotineira de dados. (Notas de versão do Odoo 20) As organizações devem verificar se direitos de acesso, regras de registro e exigências de aprovação são aplicados quando a ação offline ocorre, durante a sincronização ou em ambas as etapas. As notas de versão confirmam as ações disponíveis, mas não explicam como cada controle de segurança se comporta sem conexão.

Os testes devem usar perfis de usuário representativos, e não apenas uma conta de administrador. Cada perfil deve tentar ações permitidas e proibidas, conectado e desconectado. Em seguida, os testadores devem verificar se as alterações enfileiradas continuam visíveis, se as mensagens de rejeição estão claras e se os registros arquivados, restaurados ou excluídos chegam ao estado final pretendido. Processos em que a exclusão tem consequências significativas devem ter um procedimento offline documentado antes da implantação. (Notas de versão do Odoo 20; Odoo fica offline)

Os módulos personalizados precisam de testes direcionados

O recurso confirmado abrange as operações offline de registros do Odoo 20 e os recursos de sincronização, mas as fontes fornecidas não afirmam que todos os módulos personalizados, módulos de terceiros, ações automatizadas ou integrações externas sejam compatíveis com o trabalho offline. (Notas de versão do Odoo 20; Odoo fica offline) As implantações personalizadas devem, portanto, avaliar o suporte módulo por módulo, em vez de assumir que o modo offline se aplica de forma uniforme em toda a base de dados.

Os testes devem abranger campos personalizados, comportamento onchange, valores obrigatórios, valores calculados e verificações do lado do servidor usadas nos fluxos de trabalho da organização. As integrações que normalmente reagem à criação ou edição de registros também devem ser observadas após a sincronização das alterações enfileiradas. O objetivo não é assumir falha, mas determinar se cada elemento executa offline, aguarda a reconexão, produz um item de fila rejeitado ou exige um processo diferente. (Notas de versão do Odoo 20; Odoo fica offline)

Perguntas a resolver antes da implantação

O Odoo 20 oferece um conjunto confirmado mais amplo de recursos offline do que o Odoo 19, com suporte por uma interface dedicada e ferramentas de sincronização para trabalho enfileirado. (Documentação do Odoo 19.0: Modo offline geral; Notas de versão do Odoo 20; Odoo fica offline) Antes de confiar nesses recursos, a organização deve verificar quais aplicativos e tipos de registro estão cobertos, o que os usuários precisam abrir ou pesquisar antes da desconexão, como os conflitos são apresentados e quem monitora a sincronização com falha ou atrasada.

A decisão de implantação também deve registrar os dispositivos e ambientes de implantação suportados, o comportamento de armazenamento e retenção, os resultados de controle de acesso, os resultados dos módulos personalizados e os procedimentos para exclusão ou outras alterações relevantes. O material de versão fornecido não responde a essas questões de implementação, mas elas determinam se as funções confirmadas atendem a um fluxo de trabalho offline específico. (Notas de versão do Odoo 20; Odoo fica offline)

Para o planejamento da Community Edition, a listagem estável e recomendada do Odoo Nightly fornece o status de versão declarado, com suporte até o Odoo 23. (nightly.odoo.com) A aprovação operacional ainda deve depender de testes da versão exata, dos módulos, das permissões e dos fluxos de trabalho que os usuários levarão para o modo offline. A mudança confirmada é que o Odoo 20 vai além do acesso somente leitura do Odoo 19 aos registros anteriormente abertos, ao permitir a criação e modificação offline em fila. Os testes devem estabelecer como esse recurso se comporta na configuração da organização. (Documentação do Odoo 19.0: Modo Offline Geral; Notas de Lançamento do Odoo 20; O Odoo Fica Offline)