Introdução
Cada formulário no Odoo é composto por campos — alguns têm de ser preenchidos sempre, outros podem começar com um valor útil por defeito. O mecanismo de valores predefinidos facilita o trabalho diário ao apresentar um ponto de partida lógico antes do utilizador intervir. Por baixo desta simplicidade aparente há várias regras e fontes de verdade que convém conhecer quando se está a configurar ou a personalizar um sistema para equipas reais.
Se usa Odoo Studio para ajustes sem código ou desenvolve módulos em Python, dominar como os defaults funcionam evita horas perdidas em falhas silenciosas de configuração. Saber onde e por que um valor aparece poupa tempo e reduz retrabalho durante a implementação e a manutenção.
Este guia explica o conceito de valores predefinidos no Odoo, como são obtidos pelo ORM, quando optar por defaults estáticos ou dinâmicos e as formas de os definir — seja por Studio ou por código Python — para obter formulários mais produtivos e coerentes.
O que é um valor predefinido no Odoo
No nível do ORM, um valor predefinido é simplesmente aquilo que é atribuído a um campo quando se cria um novo registo, antes do utilizador escrever algo. Não é uma validação nem uma imposição: é um ponto de partida editável, pensado para tornar o formulário imediatamente mais útil.
Praticamente todos os tipos de campo em Odoo aceitam um default — Char, Integer, Float, Boolean, Date, Many2one, Selection, entre outros. O valor pode ser estático, uma expressão lambda em Python ou o resultado de um método; cada abordagem tem utilidade consoante a necessidade.
No Odoo Studio, os defaults surgem como um campo nas propriedades do elemento. Utilizadores sem conhecimento técnico podem definir um valor estático com alguns cliques, o que torna esta funcionalidade uma das formas mais directas de melhorar a consistência dos dados sem envolver um programador.
Os defaults não ficam gravados como propriedades da coluna na tabela do banco de dados. Podem residir na definição Python do modelo ou em registos do modelo ir.default, conforme a forma como foram criados. Quando se abre um novo registo, o Odoo lê essas fontes e pré-preenche o formulário antes do utilizador ver a página.
Como funciona o valor predefinido
Ao abrir um novo formulário, o Odoo invoca o método default_get() do modelo. Esse método compila os defaults disponíveis e devolve um dicionário com os nomes de campo e os valores a aplicar; o formulário usa esse dicionário para preencher os campos iniciais.
Existem quatro tipos principais de defaults no Odoo, cada um pensado para um cenário de uso diferente.
Defaults estáticos
Valores fixos definidos no próprio campo ou via Studio — por exemplo, marcar um Boolean como verdadeiro por defeito ou definir um Selection para 'rascunho'. São simples e suficientes para muitos casos do dia a dia, onde a mesma escolha se aplica sempre.
Defaults dinâmicos (lambda ou método)
Funções Python que correm no momento da criação do registo. Permitem recorrer à data actual, ao utilizador logado ou a outro contexto disponível. Exemplos típicos são atribuir automaticamente o utilizador responsável ou usar a data de hoje como data de documento.
Em código Python essa diferenciação fica evidente: campos com default literal versus campos que chamam uma função ou lambda para decidir o valor no momento da criação.
from odoo import fields, models
class CrmLead(models.Model):
_inherit = 'crm.lead'
# Default estático
x_priority_level = fields.Selection(
[('low', 'Low'), ('medium', 'Medium'), ('high', 'High')],
string='Priority Level',
default='medium',
)
# Default dinâmico: utilizador actual
x_assigned_by = fields.Many2one(
'res.users',
string='Assigned By',
default=lambda self: self.env.user,
)
# Default dinâmico: data de hoje
x_expected_date = fields.Date(
string='Expected Close Date',
default=lambda self: fields.Date.today(),
)Defaults baseados em contexto
É comum o Odoo passar valores de contexto usando a convenção default_field_name. Ao criar um registo a partir de outro (por exemplo, criar uma tarefa a partir de um projecto), o contexto pré-preenche campos relacionais com o registo associado. Este mecanismo é essencial nas navegações e pode ser configurado por desenvolvedores ou utilizadores avançados para manter os fluxos de trabalho intuitivos.
Defaults ao nível do utilizador com ir.default
O modelo ir.default permite definir defaults específicos por utilizador. Um administrador pode configurar um valor preferencial para um determinado utilizador, e esse default prevalece sobre o definido no modelo. Em ambientes com várias pessoas, isto oferece flexibilidade para preferências individuais sem alterar o comportamento global.
Ordem de prioridade
Quando existem várias fontes para o mesmo campo, a resolução obedece a uma ordem: primeiro os ir.default configurados para o utilizador, depois os ir.default
Cenários empresariais práticos
Os defaults aparecem em quase todos os módulos do Odoo. A seguir estão cinco exemplos práticos retirados de fluxos reais de trabalho empresarial.
CRM: vendedor predefinido em leads novos
Ao criar um lead, o campo Responsável costuma vir preenchido com o utilizador actual. Assim evita-se que todos os leads fiquem sem dono e obriguem a atribuições manuais. Este pequeno ajuste aumenta a adoção do CRM porque os utilizadores veem logo os seus leads sem passos adicionais.
Vendas: condições de pagamento predefinidas
Num pedido de venda, a tabela de preços e as condições de pagamento vêm normalmente do registo do cliente. Um cliente com condição '30 dias' terá essa condição aplicada automaticamente em novos pedidos, reduzindo erros e garantindo que os termos negociados são usados mesmo quando vários vendedores criam ordens.
Inventário: localizações predefinidas em transferências
Ao registar uma transferência interna, os campos de origem e destino tendem a preencher-se com as localizações definidas nas configurações do armazém. Operadores que trabalham sempre numa zona específica encontram as localizações correctas já selecionadas, poupando cliques e minimizando erros sob pressão.
Contabilidade: diário predefinido em lançamentos
Ao criar uma fatura ou fatura de fornecedor, o diário apropriado é escolhido automaticamente com base no tipo de lançamento e nas configurações da empresa. Um contabilista não precisa de seleccionar manualmente o diário para cada fatura, porque o default é resolvido dinamicamente a partir das definições da empresa.
Projectos: etapa predefinida em novas tarefas
Uma nova tarefa criada dentro de um projecto começa na primeira etapa da configuração kanban desse projecto. Se a tarefa for aberta a partir do cartão do projecto, o contexto também pode preencher o projecto e o responsável. Isto mantém as tarefas no lugar correcto desde o início, sem necessidade de ajustes manuais.
Criar ou adaptar valores predefinidos
Há três formas principais de definir defaults no Odoo: sem código via Studio, por código em Python, ou criando registos ir.default programaticamente.
Via Odoo Studio (sem código)
O Studio oferece uma interface visual para definir defaults em qualquer campo do formulário. É a via rápida para aplicar defaults estáticos sem tocar em código.
- Abrir o Studio no formulário que pretende alterar
- Selecionar o campo a configurar
- Na coluna de propriedades do campo, localizar o campo "Default Value"
- Inserir ou escolher o valor que pretende usar por defeito
- Guardar e sair do Studio
O Studio grava essa escolha como um registo ir.default na base de dados, aplicável por defeito a toda a empresa salvo se restringir por utilizador. Funciona particularmente bem para Selection, Boolean, Char e Integer; para campos Many2one o Studio permite escolher um registo existente. É uma forma prática de criar campos e definir defaults sem programar.
Lembre-se: alterar o default via Studio não actualiza registos já existentes — só se aplica a registos criados depois da alteração.
Via Python em personalizações técnicas
Em personalizações técnicas, define-se o default directamente na declaração do campo no modelo Python. Isto dá controlo total sobre defaults estáticos, lambdas e métodos, e é a abordagem recomendada sempre que o valor depende de informação em tempo de execução (utilizador, data, empresa, etc.).
Exemplo de diferentes tipos de defaults numa extensão de módulo customizado:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
# Booleano por defeito
x_requires_review = fields.Boolean(
string='Requires Review',
default=False,
)
# Selection por defeito
x_delivery_preference = fields.Selection(
[('standard', 'Standard'), ('express', 'Express')],
string='Delivery Preference',
default='standard',
)
# Default dinâmico via método
def _default_note(self):
return self.env['ir.config_parameter'].sudo().get_param(
'sale.default_note', default=''
)
x_internal_note = fields.Text(
string='Internal Note',
default=_default_note,
)Este padrão segue as convenções de desenvolvimento Odoo em Python e aplica-se a todos os tipos de campo. Defaults baseados em métodos são úteis quando a lógica é mais complexa do que uma simples lambda.
Criar/actualizar registos ir.default programaticamente
Também é possível criar registos ir.default via API (XML-RPC) ou através de ficheiros de dados num módulo. Isto é útil quando se pretende instalar uma configuração por defeito como parte do processo de instalação do módulo, incluindo o âmbito por empresa ou utilizador.
Embora menos frequente no dia a dia, esta abordagem é valiosa quando se distribui módulos instaláveis que devem definir defaults sensatos automaticamente durante a instalação.
Boas práticas para valores predefinidos no Odoo
Defina defaults para campos obrigatórios
Se um campo é obrigatório, atribua-lhe um default razoável sempre que possível. Isto reduz fricção e evita erros de gravação quando alguém tenta criar um registo sem perceber que o campo é obrigatório. Combinar required=True com um default prático é uma boa prática.
Use lambdas para defaults de data
Nunca codifique uma data fixa como default. Utilize lambda self: fields.Date.today() para garantir que a data é calculada no momento da criação. Um valor fixo ficará desactualizado rapidamente e causará resultados incorrectos para registos futuros.
Mantenha a lógica de default leve
Default_get e funções de default correm cada vez que se inicia a criação de um registo. Evite consultas pesadas, chamadas a APIs externas ou cálculos demorados nesses métodos. Se precisar de lógica mais complexa, considere um onchange ou um campo computado desencadeado por outra alteração em vez de carregar o default com processamento pesado.
Use defaults de contexto para fluxos de navegação
Ao construir ações personalizadas ou botões que abrem formulários, passe valores com default_field_name no contexto em vez de confiar apenas no default do modelo. É assim que muitos botões nativos funcionam e mantém a customização alinhada com as convenções do Odoo.
Teste defaults com múltiplos perfis de utilizador
Defaults que referenciam self.env.user ou self.env.company podem comportar-se de forma diferente consoante o utilizador. Teste com diferentes contas e em cenários multi-empresa para validar o comportamento. O que funciona para um administrador pode não ser adequado para um utilizador padrão.
Erros comuns a evitar
Evite usar objectos mutáveis como default
Não escreva default=[] ou default={} — isto partilha o mesmo objecto entre instâncias e leva a dados contaminados entre registos. Use uma lambda: default=lambda self: [] para criar uma nova estrutura em cada inicialização.
Defaults não disparam onchange
Atribuir um default não activa os métodos onchange. Se uma mudança de campo normalmente desencadeia actualizações noutros campos via onchange, esse mecanismo não ocorrerá quando o campo é apenas predefinido. Se precisar que o onchange corra na inicialização, terá de o invocar explicitamente numa sobrescrita de default_get ou implementar a lógica de outra forma.
Conflitos entre ir.default e definição do modelo
Se definir um default em Python e também via Studio (ir.default), o registo ir.default prevalece. Esta prioridade é uma fonte frequente de confusão quando uma alteração no Studio parece "ignorar" um default implementado por um programador.
Não confunda default com obrigatoriedade
Ter um default não torna o campo obrigatório: o utilizador pode apagar o valor e gravar em branco. Não dependa apenas do default para garantir completude dos dados; se um valor for sempre necessário, combine default com required=True.
Não referencie IDs rígidos de empresa ou utilizador
Usar default=1 para apontar para um registo por ID é frágil — em ambientes diferentes o mesmo registo terá outro ID. Em vez disso, recorra a referências dinâmicas como lambda self: self.env.company.id ou lambda self: self.env.ref('module.xml_id').id para obter robustez entre bases de dados distintas.
Conclusão
Valores predefinidos são uma funcionalidade pequena mas poderosa no modelo de dados do Odoo. Reduzem introdução manual de informação, orientam escolhas consistentes e tornam os formulários mais fáceis de usar. Quer os defina com Studio para uma solução rápida sem código, quer os implemente em Python para cenários mais sofisticados, compreender os defaults ajuda a criar implementações Odoo mais eficazes.
Pontos-chave a reter: defaults correm apenas na criação de registos; não disparam onchange; várias fontes obedecem a uma ordem de prioridade bem definida; e nunca use listas ou dicionários mutáveis directamente como default sem envolver uma lambda.
Acertar nos defaults costuma ser a diferença entre um formulário intuitivo e outro que atrapalha os utilizadores a cada nova criação de registo. É um pequeno esforço de configuração com retorno diário em produtividade e qualidade dos dados.
Na Dasolo ajudamos empresas a implementar, personalizar e optimizar o Odoo para os seus fluxos de trabalho específicos. Se precisa de apoio para configurar defaults, criar campos personalizados ou desenhar um modelo de dados que funcione para a sua equipa, podemos colaborar consigo. Contacte‑nos para conversarmos sobre a sua implementação Odoo.