Os campos readonly no Odoo parecem simples à primeira vista, mas influenciam fortemente a forma como processos, auditorias e integrações se comportam numa implementação.
Se já reparou que alguns campos aparecem bloqueados no ecrã ou se é um desenvolvedor a querer controlar a edição de dados, este guia mostra o que precisa de saber para gerir esses comportamentos com segurança.
Compreender quando e por que tornar um campo não editável é essencial para evitar inconsistências, preservar a fiabilidade dos relatórios e proporcionar uma experiência de utilizador previsível.
Nesta explicação verá tanto a perspetiva de negócio como a técnica sobre campos readonly, útil quer esteja a configurar Odoo sem código quer a desenvolver módulos personalizados.
O que significa o atributo readonly no Odoo
Num produto Odoo, um campo readonly mostra um valor ao utilizador mas não permite alterações através da interface — está visível, mas sem possibilidade de edição direta.
Numa vista de formulário, esses campos aparecem normalmente como texto estático em vez de caixas de entrada. Visualmente podem parecer atenuados ou simplesmente não interativos, consoante o tema e o layout.
No Odoo existem duas formas principais de aplicar o comportamento readonly:
- Ao nível do campo (Python/ORM): o campo fica readonly de forma permanente em todas as vistas e contextos
- Ao nível da vista (XML): o campo fica readonly apenas naquela vista ou sob determinadas condições
Esta diferença é crucial: se bloquear um campo no modelo (ORM), ninguém o poderá alterar via interface; se o bloquear apenas na vista, ele pode continuar editável noutras vistas ou por código do servidor.
Readonly não é um tipo de campo — é um atributo que se aplica a qualquer tipo de campo Odoo: Char, Integer, Float, Many2one, Date, etc. É uma ferramenta central para controlar a interação com os dados.
Como funciona o atributo readonly
Para dominar o comportamento readonly é útil olhar para o backend (ORM em Python) e para a camada de apresentação (XML) para ver como ambos controlam a edição.
Readonly no nível do ORM
No ORM do Odoo, pode definir um campo como readonly na declaração do modelo Python. É frequente em campos computados cujo valor resulta de cálculos: inclui-se readonly=True na definição e a interface nunca permitirá escrita direta.
Este uso faz parte da API de campos do Odoo e aplica-se globalmente, independentemente da vista em que o registo seja mostrado.
Readonly condicionado pelo estado
Um padrão comum é tornar campos não editáveis conforme o estado do documento — por exemplo, bloquear campos assim que um registo deixa o estado rascunho. Módulos padrão como Vendas e Contabilidade usam este padrão para proteger dados finais.
Até Odoo 16 era habitual controlar isso com o atributo attrs no XML. A partir do Odoo 17 existe uma sintaxe inline mais limpa para expressar essas condições diretamente no elemento do campo.
Ambas as abordagens têm o mesmo objetivo: o campo é editável enquanto o documento está em rascunho e fica bloqueado quando avança na workflow. É um conceito fundamental em qualquer configuração de campos.
Campos computados e readonly
Por defeito, campos com compute são readonly — o Odoo presume que não devem ser alterados manualmente porque o seu valor é calculado a partir de outros dados.
Se precisar de guardar o resultado no banco de dados, define-se compute com store=True. Os campos armazenados melhoram desempenho e permitem pesquisas e ordenação sem recalcular tudo em tempo de execução.
Tornar um campo computado editável
Para aceitar entrada manual num campo computado é preciso definir um método inverse que diga ao Odoo como interpretar a escrita do utilizador. Sem esse inverse, o campo permanece readonly. Esta é uma funcionalidade avançada da API do ORM.
Casos práticos de negócio
Campos readonly surgem em todos os módulos do Odoo. Abaixo estão exemplos práticos que ilustram por que e quando os usamos numa empresa.
1. CRM: registos de oportunidades encerradas
No CRM, valores como receita esperada ou data de fecho são alteráveis durante a negociação. Quando a oportunidade é marcada como ganha ou perdida, esses campos ficam bloqueados para manter um histórico fidedigno.
Isto evita que alguém ajuste números retroativamente e quebre a integridade dos relatórios comerciais.
2. Vendas: linhas de encomenda confirmadas
Ao confirmar uma encomenda, as linhas deixam de poder ser alteradas — produto, quantidade e preço ficam protegidos após o cliente receber a confirmação.
Se for necessário alterar algo, o fluxo exige reabrir a encomenda para rascunho, criando um rasto de auditoria e tornando a alteração intencional.
3. Inventário: quantidades validadas
Nas operações de armazém, após validar uma expedição ou receção, as quantidades registadas ficam bloqueadas para garantir que a valorização de stock e os registos reflitam o movimento físico.
Permitir edições pós-validação pode corromper níveis de stock entre locais e prejudicar relatórios de inventário.
4. Contabilidade: lançamentos contabilísticos publicados
Depois de um lançamento ser publicado, as linhas ficam readonly — requisito importante para conformidade legal e integridade das demonstrações financeiras.
Editar lançamentos pós-publicação comprometeria a fiabilidade das contas e poderia violar legislações fiscais.
5. Produção: ordens de trabalho concluídas
Em produção, quando uma ordem de trabalho é marcada como concluída, durações e quantidades produzidas ficam bloqueadas para preservar dados de custo e desempenho.
Criar ou personalizar um campo readonly
Existem duas formas principais de configurar campos readonly: usar Odoo Studio sem código ou escrever Python/XML para controlo técnico total.
Usar Odoo Studio
Odoo Studio permite marcar um campo como readonly sem tocar em código. É ideal para administradores e consultores que precisam de regras rápidas e seguras.
- Abra o Odoo Studio a partir do menu principal (ícone do lápis)
- Vá até à vista de formulário onde pretende alterar o campo
- Clique no campo que quer modificar
- No painel de propriedades à direita, active a opção "Readonly"
- Guarde as alterações e saia do Studio
No Studio também pode aplicar readonly condicional através de expressões de domínio — por exemplo, bloquear um campo quando um estado específico estiver selecionado — sem escrever código.
A abordagem Studio é a escolha correta quando quer mudanças rápidas, seguras e que sobrevivem a atualizações de módulos, perfeita para consultores e administradores.
Usar Python para personalização técnica
Para desenvolvedores que criam módulos, define-se readonly na declaração do campo no ficheiro Python do modelo. Esta é a prática standard na personalização técnica do Odoo.
Pode usar readonly=True para bloqueio permanente, ou o parâmetro states para especificar em que estados do documento o campo é editável ou não.
Esta abordagem mantém a lógica junto ao modelo de dados — útil quando adiciona campos personalizados a modelos existentes como parte de um projecto de personalização.
Usar atributos na vista XML
For view-level readonly behavior, you add the readonly attribute directly to the field element in your view XML. This is part of the standard Odoo development workflow for any technical customization.
A vantagem de controlar ao nível da vista é a flexibilidade: o mesmo campo pode ter comportamentos diferentes conforme a vista ou condição, sem alterar a definição no Python.
No Odoo 17 a sintaxe inline para condições readonly é mais clara que o antigo attrs, embora ambos sejam válidos conforme a versão do Odoo que estiver a usar.
Boas práticas
Saber aplicar readonly corretamente significa escolher o nível certo e justificar a restrição com base no processo de negócio. Aqui estão recomendações práticas para consultoria Odoo.
1. Prefira readonly ao nível da vista quando o contexto variar
Se o campo só precisa de ser bloqueado em algumas vistas ou estados, aplique readonly na vista. Assim, processos de backend ou integrações API ainda podem escrever no campo quando necessário.
2. Alinhe as condições com o ciclo de vida do documento
Bloqueie campos quando o estado do documento justificar — por exemplo, quando uma alteração poderia causar inconsistências. Isso cria uma experiência previsível para os utilizadores.
3. Teste com diferentes perfis de utilizador
O comportamento readonly pode ser afectado por direitos de acesso. Teste como um utilizador normal e como administrador para garantir que o efeito é o esperado para cada perfil.
4. Combine readonly com required quando fizer sentido
Em formulários com várias etapas, pode ser necessário que um campo seja obrigatório em rascunho e depois readonly. Combine ambos atributos na vista para implementar esse padrão.
5. Documente a lógica por trás do readonly
Em desenvolvimentos personalizados, acrescente comentários que expliquem a razão de negócio para um campo ser readonly — isso ajuda quem mantiver o código no futuro.
6. Use Studio para alterações rápidas e compatíveis com upgrades
Reserve alterações em Python para quando Studio não consegue representar a lógica necessária, por exemplo condições cross-field complexas ou interacção com campos computados personalizados.
Erros comuns a evitar
Mesmo utilizadores experientes tropeçam nos mesmos problemas com readonly. Conheça os erros mais frequentes para os evitar.
Confundir readonly de vista com uma barreira de segurança
Readonly na vista limita apenas a interface. APIs (XML-RPC), chamadas ORM no servidor ou ações automatizadas ainda podem alterar o campo. Para impedir totalmente gravações, implemente a restrição no ORM ou através de regras de acesso.
Tornar um campo permanentemente readonly quando deveria ser condicional
Bloquear um campo no modelo pode impedir correções legítimas, como reabrir um documento para rascunho. Pense no ciclo de vida completo antes de optar por readonly permanente.
Esquecer métodos onchange
Um onchange pode tentar escrever num campo readonly e causar comportamentos estranhos — alterações temporárias no ecrã, reverts ou erros. Garanta que a lógica onchange respeita campos não editáveis.
Não aplicar readonly de forma consistente em todas as vistas
Colocar readonly apenas no formulário pode deixar o campo editável em listas ou kanban. Verifique todas as vistas onde o campo aparece para garantir consistência.
Efeitos colaterais ao herdar modelos padrão
Ao herdar um modelo padrão e definir readonly=True num campo existente, essa alteração afecta todas as vistas que exibem o campo, incluindo as standard. Confirme que é intencional e não causa conflitos com outras personalizações.
Resumo
Campos readonly são uma ferramenta essencial no Odoo para orientar utilizadores, proteger a consistência dos dados e aplicar regras de negócio de forma prática.
O mais importante é aplicar readonly ao nível adequado — vista ou modelo — e garantir que as condições refletem o modo real de trabalho da equipa.
Quer opte por Studio para uma solução sem código ou por Python/XML para controlo técnico, a filosofia mantém-se: mostrar informação, mas evitar alterações não desejadas.
Podem não ser o tema mais comentado nas personalizações, mas o impacto deles nas operações diárias é grande.
Na Dasolo apoiamos empresas a implementar, personalizar e optimizar Odoo em todos os módulos. Se precisa de ajuda a configurar campos, desenhar fluxos de trabalho ou melhorar o seu modelo de dados, a nossa equipa está disponível. Fale connosco e conte-nos sobre o seu projeto.