Introdução
Se, ao preencher um formulário no Odoo, um campo ficou vermelho e impediu o registo, já experimentou o comportamento de um campo obrigatório. É uma funcionalidade básica do modelo de dados do Odoo que ajuda a garantir que informação crítica não fica por preencher nos processos da empresa.
Quer esteja a configurar Odoo para a equipa de vendas, a criar um modelo personalizado ou a desenvolver um módulo técnico, saber como funciona a propriedade required permite construir fluxos mais robustos e evitar erros evitáveis.
Este guia explica tudo: o comportamento do campo dentro do framework Odoo, formas de o configurar com Odoo Studio ou código Python, quando é apropriado usá-lo e armadilhas comuns a evitar.
O que Significa "Obrigatório" no Odoo
No Odoo, a flag required é uma restrição ao nível do campo que impede a gravação de um registo enquanto esse campo estiver vazio. Aplica-se à maioria dos tipos de campo: textos, números, escolhas, many2one, datas, entre outros.
Faz parte do núcleo do modelo de dados do Odoo e é uma das propriedades mais usadas em personalizações. Marcar um campo como obrigatório é a forma mais simples de reduzir registos incompletos ou incoerentes na base de dados.
Como Isto se Mostra na Interface
Na interface do Odoo, os campos obrigatórios são diferenciados dos opcionais. Em edição, normalmente apresentam um indicador visual e, ao tentar gravar sem preencher um campo obrigatório, o sistema assinala-o em vermelho e mostra uma mensagem de aviso.
Esse feedback imediato e claro na interface ajuda os utilizadores a corrigir problemas antes de gravar, diminuindo registos incompletos.
Obrigatório Estático vs. Dinâmico
Existem duas formas de tornar um campo obrigatório: um obrigatoriedade estática — o campo é sempre obrigatório — e uma obrigatoriedade dinâmica — o campo só é obrigatório quando certas condições são satisfeitas, normalmente com base em outros campos do mesmo registo.
Ambas as abordagens são usadas com frequência. A escolha depende das regras de negócio que pretende implementar.
Como Esse Mecanismo Funciona
Compreender o funcionamento técnico do atributo required ajuda a aplicá-lo corretamente e a resolver problemas quando surgem.
Validação no Nível da Aplicação
Um detalhe importante e por vezes surpreendente: a validação do required é feita no nível da aplicação, pelo ORM do Odoo, e não adiciona necessariamente uma restrição NOT NULL na tabela PostgreSQL.
Colocar required=True num campo valida-o em Python através do ORM antes de a operação chegar à base de dados; por isso, a coluna do PostgreSQL nem sempre tem um constraint NOT NULL associado por defeito.
Na prática, isto significa que dados inseridos diretamente na base de dados contornando o Odoo não são validados pelo required. Por isso, interaja sempre com os dados através do ORM ou da API para garantir a proteção das regras definidas.
O Que Acontece Quando a Regra é Violada
Ao tentar gravar um formulário com um campo obrigatório vazio, sucedem dois efeitos principais:
- o campo fica marcado em vermelho na interface e aparece uma mensagem de validação
- a operação de gravação é bloqueada até o campo ser preenchido
Se a validação for disparada por código (por exemplo via XML-RPC ou ação de servidor), o Odoo levantará um ValidationError indicando qual o campo em falta.
Obrigatoriedade Dinâmica com Domains/Expressões
No framework do Odoo, o comportamento obrigatório pode ser condicionado ao nível da vista. Em versões anteriores usa-se attrs no XML da vista para definir essa lógica.
Exemplo (estilo antigo): <field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />
A partir de versões mais recentes, a sintaxe simplificou-se e permite expressões diretas no atributo required da tag field.
Exemplo (estilo novo): <field name="x_delivery_date" required="order_type == 'delivery'" />
Essas regras condicionais existem na camada de vista, não no modelo: um required=True no modelo é sempre aplicado, enquanto as expressões na vista só se aplicam naquele contexto de interface específico.
Interação com o ORM e a API
Quando usa create() ou write() sobre um modelo, o ORM verifica os campos com required=True antes de executar a operação. Se faltar um campo obrigatório ou for False, o Odoo lança um ValidationError.
Isto aplica-se igualmente quando cria registos via XML-RPC: os campos definidos como obrigatórios no modelo têm de constar no dicionário de dados passado para create, caso contrário a chamada falha.
Cenários Reais de Negócio
Exemplos práticos mostram onde os campos obrigatórios mais contribuem para fluxos de negócio mais confiáveis; seguem cinco situações concretas retiradas de processos reais.
1. CRM: Segmento de Cliente Obrigatório em Leads
Uma equipa comercial precisa que cada lead tenha um segmento atribuído antes de avançar para o pipeline; sem essa obrigatoriedade, muitos leads chegam sem essa classificação, impossibilitando relatórios fiáveis por segmento.
Tornar o campo personalizado “Segmento de Cliente” obrigatório no formulário de lead assegura que a informação é capturada no momento da entrada — sem segmento, não há gravação.
2. Vendas: Morada de Entrega Obrigatória em Encomendas
Para empresas que enviam mercadorias, a morada de entrega é essencial. Em algumas configurações do Odoo esse campo não é obrigatório por defeito, permitindo confirmar encomendas sem morada.
Exigir a morada de entrega no formulário de encomenda impede confirmações sem a informação logística necessária, reduzindo falhas no cumprimento das encomendas.
3. Inventário: Número de Lote/Serie Obrigatório na Receção
Em sectores regulados (alimentar, farmacêutico, eletrónica), o rastreio de lotes é obrigatório. Odoo oferece suporte nativo através do rastreamento de produtos, que obriga ao número de lote/serie em movimentos de stock quando configurado.
Para campos personalizados nas fichas de receção, como referências de controlo de qualidade, torná-los obrigatórios garante que a equipa de armazém regista sempre essa informação.
4. Contabilidade: Centro de Custo Obrigatório em Faturas de Fornecedor
Equipas financeiras frequentemente exigem que cada despesa seja atribuída a um centro de custo para controlo orçamental. Sem essa exigência, faturas podem ficar sem essa referência, criando lacunas nos relatórios.
Adicionar um many2one obrigatório para o centro de custo no formulário de fatura garante que nenhuma fatura é contabilizada sem essa atribuição, melhorando a integridade dos dados.
5. RH: Tipo de Contrato Obrigatório Antes da Integração
Nos processos de onboarding, o RH quer o tipo de contrato definido antes de finalizar o registo do trabalhador. Um campo obrigatório no formulário do empregado evita gravar registos incompletos durante períodos com muitas contratações.
Criar ou Personalizar Campos Obrigatórios
Existem duas formas principais de tornar um campo obrigatório: por Odoo Studio (sem código) ou por código Python (maior controlo). A escolha depende das necessidades e complexidade do cenário.
Usar o Odoo Studio
Odoo Studio é a ferramenta no-code que permite marcar campos como obrigatórios sem escrever código. Ao editar um formulário com Studio, encontra um interruptor “Required” nas propriedades do campo.
Ativar essa opção torna o campo obrigatório na vista e grava a configuração no modelo — é a forma mais rápida para casos simples e funciona bem para campos padrão e personalizados criados via Studio.
A limitação do Studio é que normalmente só implementa uma obrigatoriedade estática. Para comportamentos condicionais com base em outros campos, será necessário editar o XML da vista ou optar pela abordagem técnica.
Abordagem Técnica: Campos em Python
Num módulo personalizado, basta declarar required=True na definição do campo para torná-lo obrigatório no nível do modelo. Este é o padrão em desenvolvimento Python no Odoo.
Exemplo de definição em Python (padrão): from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'PME'),
('enterprise', 'Empresa'),
('public', 'Setor Público'),
],
string='Segmento de Cliente',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Centro de Custo',
required=True,
)
Com esta opção, a restrição aplica-se ao nível do modelo, ou seja, vale independentemente da vista ou interface usada para criar ou editar o registo e não pode ser contornada por outra vista.
Obrigatoriedade Dinâmica no XML da Vista
Se a obrigatoriedade só faz sentido em determinadas condições, defina-a na vista em vez do modelo. Em versões antigas usa-se attrs no XML.
Exemplo (estilo antigo): <field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />
Em versões mais recentes a sintaxe simplifica-se:
Exemplo (estilo novo): <field name="x_cost_center_id"
required="order_type == 'invoiced'" />
Esta obrigatoriedade existe apenas na vista que a define — é menos rígida que uma obrigatoriedade a nível de modelo porque só se aplica quando o registo é editado por essa vista específica.
Criar Campos Obrigatórios via API
Também é possível criar campos e definir required programaticamente usando a API XML-RPC ao criar registos em ir.model.fields. Isto é útil em cenários de automatização e deployment.
Exemplo de criação por API: models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)
Este processo cria o campo e aplica a obrigatoriedade numa só operação, conveniente para fluxos de deploy automatizados.
Boas Práticas
Marcar um campo como obrigatório é simples, mas exige reflexão. Estas práticas ajudam a reduzir fricção para utilizadores e a manter a qualidade dos dados.
1. Torne um Campo Obrigatório Só Quando For Realmente Necessário
Exigir demasiados campos é um erro comum: se a informação não estiver normalmente disponível no momento da criação, os utilizadores vão contornar a regra com valores fictícios, degradando a qualidade dos dados.
Antes de definir um campo como obrigatório, pergunte-se se essa informação existe sempre no ponto de entrada. Se não, considere exigir o campo numa fase posterior do processo (por exemplo, na confirmação) ou usar uma obrigatoriedade dinâmica.
2. Prefira Validação por Fase em Processos Multietapa
Em fluxos com várias fases (oportunidades, ordens de fabrico), é muitas vezes melhor validar campos em pontos específicos do processo em vez de os tornar obrigatórios desde a criação. Isso faz-se com constraints em Python ou ações automáticas quando o registo muda de estado.
Esse padrão é mais flexível e menos intrusivo para os utilizadores do que exigir todos os campos desde o início.
3. Combine Campos Obrigatórios com Valores Por Omissão Quando Faz Sentido
Se um campo for normalmente preenchido com um valor padrão, defina um default na sua definição. Isso reduz atrito para os utilizadores que não precisam de alterar o valor, mantendo o campo sempre preenchido.
4. Use Obrigatoriedade ao Nível do Modelo para Dados Críticos
Para informações realmente críticas (dados contabilísticos, identificadores regulamentares), aplique a restrição no modelo em Python. Obrigações apenas na vista podem ser contornadas por importações, API ou outras vistas que não incluam a regra.
5. Avise os Utilizadores sobre Mudanças de Campos Obrigatórios
Ao adicionar campos obrigatórios a formulários existentes, comunique a mudança à equipa antes do deploy. Utilizadores com registos em curso podem ver erros inesperados ao editar registos que agora exigem novos campos.
6. Teste com Dados Vazios e Parciais
Antes de colocar em produção, teste os fluxos completos com valores vazios e parciais — pela interface web, pela API e por qualquer integração ou ação automática que crie registos. Testes abrangentes evitam surpresas depois do go-live.
Erros Frequentes
Mesmo implementadores experientes tropeçam em armadilhas com campos obrigatórios. Conhecer os pontos de atenção poupá-lo-á a muitas horas de depuração.
Armadilha 1: Tornar Obrigatório um Campo Num Modelo com Registos Existentes
Se adicionar required=True a um campo num modelo que já contém muitos registos sem esse valor, os utilizadores vão encontrar erros ao tentar editar esses registos — não conseguirão gravar alterações até preencherem o campo.
Antes de impor a obrigatoriedade, verifique se os registos existentes têm valores; caso contrário, execute uma migração para povoar o campo primeiro.
Armadilha 2: Confundir Obrigatoriedade de Vista com a do Modelo
Definir um campo como obrigatório apenas na vista (via Studio ou XML) não garante que a regra seja aplicada em todos os contextos. Registos criados pela API, por outra vista ou por importação contornam obrigatoriedades apenas de vista.
Se precisa de uma restrição rígida, use required=True na definição Python do campo. Esta confusão é uma fonte comum de problemas de qualidade de dados em produção.
Armadilha 3: Ações Automáticas que Criam Registos sem Todos os Campos Obrigatórios
Ações automáticas ou ações agendadas que criam registos têm de fornecer valores para todos os campos obrigatórios. Se um campo obrigatório for adicionado depois da ação ter sido escrita, essa ação começará a falhar até ser atualizada.
Revise qualquer código que crie registos automaticamente após adicionar um campo obrigatório a um modelo existente.
Armadilha 4: Importações que Não Incluem Campos Obrigatórios
Ao importar via CSV ou pela ferramenta de importação do Odoo, campos obrigatórios ausentes provocam a falha da importação. É o comportamento correto, mas surpreende quem está habituado a importar dados incompletos.
Inclua sempre os campos obrigatórios nos templates de importação e documente quais os campos que são necessários nas suas directrizes de importação.
Armadilha 5: Usar required quando Precisa de Validação Lógica Complexa
O atributo required apenas verifica se um campo está preenchido; não valida o conteúdo nem relações entre campos. Para regras mais complexas (por exemplo, garantir que uma data é futura ou que dois campos são coerentes), use um @api.constrains em Python.
Tentar codificar lógica de negócio complexa apenas com required leva a configurações inflexíveis e difíceis de manter.
Resumo
O atributo de campo obrigatório é uma ferramenta simples mas poderosa no Odoo: bem aplicada, garante que informação crítica é sempre capturada no momento certo; mal aplicada, gera frustração e dados pouco fiáveis.
A chave é perceber a diferença entre obrigatoriedade a nível de modelo e de vista, ser criterioso quanto aos campos que devem ser exigidos e antecipar o impacto em automações e integrações.
Quer esteja a seguir um guia de desenvolvimento, a personalizar o Odoo para a sua empresa ou a ajustar um formulário no Studio, compreender bem o required faz a diferença entre uma implementação limpa e uma que causa problemas passados alguns meses.
Precisa de Ajuda com a Implementação do Odoo?
Na Dasolo, apoiamos empresas a implementar, personalizar e otimizar o Odoo em todas as áreas e complexidades. Se precisa de ajuda a desenhar um modelo de dados robusto, configurar regras de validação ou desenvolver módulos personalizados, a nossa equipa tem experiência técnica e funcional para o seu projeto.
Se tiver dúvidas sobre campos obrigatórios ou qualquer outro aspeto do seu Odoo, estamos disponíveis para ajudar. Contacte-nos e vamos conversar sobre o que pretende construir.