Introdução
Ao trabalhar com desenvolvimento em Odoo, um princípio aparece constantemente: a capacidade de estender modelos. A arquitetura do ORM do Odoo foi pensada para que diferentes modelos partilhem atributos e comportamentos sem duplicar armazenamento nem multiplicar código desnecessário.
Os campos herdados são a peça-chave desse desenho. Eles permitem que um modelo exponha e utilize campos definidos fisicamente noutro modelo, sem ter de copiar os dados. Quando se percebe este mecanismo, muitas decisões de modelação ficam muito mais claras.
Este guia mostra de forma prática o que são campos herdados, as três formas de herança de modelos que originam esses campos, como o dado é armazenado, e quando usar cada abordagem em personalizações reais do Odoo.
O que é um campo herdado no Odoo?
No ORM do Odoo, consideramos um campo como herdado quando um modelo passa a aceder a campos definidos noutro modelo através de uma das três formas de herança suportadas. Em vez de recriar o campo, o modelo filho reutiliza-o.
É essa reutilização que torna o modelo de dados do Odoo compacto e coerente. Por exemplo, o mesmo campo nome de um contacto é apresentado em vendas, CRM e facturação porque todos leem a partir de uma fonte comum.
As três formas de herança no Odoo
O Odoo oferece três formas distintas de herança de modelos, e cada uma trata os campos e o armazenamento de maneira diferente.
1. Herança clássica
Esta é a abordagem mais habitual: usa-se _inherit sem declarar um novo _name. Nesse caso estende-se diretamente o modelo existente — adicionam-se campos e métodos — sem criar nova tabela na base de dados. Os campos passam a fazer parte do modelo original.
É assim que a maioria dos módulos acrescenta campos a modelos padrão. Ao instalar o módulo de CRM, por exemplo, são adicionados campos a res.partner via herança clássica, e esses campos ficam armazenados na tabela de parceiros junto com os campos centrais.
2. Herança por protótipo
Aqui combina-se _inherit com _name. O novo modelo nasce com a estrutura do pai, mas obtém a sua própria tabela na base de dados; os campos do pai são replicados no filho. Modificações no filho não alteram o pai.
Este padrão é menos usado em personalizações rotineiras, mas é útil quando precisamos de criar um modelo novo que partilha a estrutura de outro já existente.
3. Herança por delegação
A herança por delegação emprega _inherits. O modelo filho mantém um vínculo Many2one para o pai e expõe, de forma transparente, todos os campos do pai como se fossem seus. Os dados efetivamente residem na tabela do pai, não na do filho.
É este tipo que a maioria dos desenvolvedores referencia quando fala de campos herdados no sentido estrito: os campos não são duplicados, são acedidos através da relação sempre que necessário.
Um exemplo claro na base do Odoo é a relação entre res.users e res.partner. Cada utilizador é também um contacto: o nome, o email e o telefone residem no parceiro e são acedidos pelo utilizador por delegação.
Como funciona o campo
Como funciona a delegação internamente
Quando se usa _inherits, o ORM constrói uma ponte lógica entre duas tabelas. Ao ler um campo herdado do registo filho, o Odoo segue automaticamente a ligação Many2one até ao registo pai e devolve o valor armazenado aí.
Ao escrever num campo herdado a partir do filho, o ORM escreve diretamente no registo pai. Para o programador o campo parece nativo; para a base de dados, o dado vive na tabela do pai.
Isto evita duplicação de dados: uma alteração no nome do parceiro propaga-se imediatamente para todos os pontos que o referenciam, incluindo o utilizador que dele depende.
Herança clássica e a base de dados
Com herança clássica, os novos campos são adicionados à tabela do modelo original — não há tabelas adicionais. No nível da base de dados, modelo estendido e modelo original são o mesmo objecto. Esta é, habitualmente, a abordagem mais limpa para personalizações.
Campos related como herança leve
Um campo related é um campo computado especial que lê um valor de um registo ligado através de uma cadeia de relações. Não é exactamente herança de modelo, mas é frequentemente usado para expor dados terceirizados num modelo sem alterar a sua estrutura.
Por exemplo, no pedido de venda se pode ter um campo partner_country_id que lê partner_id.country_id. O campo parece nativo no pedido, mas o seu valor vem do parceiro.
Campos related podem ser armazenados com store=True, o que melhora buscas e filtros, mas aumenta o espaço ocupado e exige recomputação quando a fonte muda.
Como os campos são resolvidos em tempo de execução
Quando o Odoo carrega a definição de um modelo, resolve o mapa completo de campos, incluindo os herdados. Antes do modelo ficar disponível, o Odoo já associou cada campo à sua fonte — tabela própria, tabela pai via delegação, ou cadeia related. Esta resolução é feita no arranque do servidor e é colocada em cache para desempenho.
Casos de uso na empresa
Além da técnica, os campos herdados resolvem problemas concretos de negócio ao manter a informação consistente entre módulos sem redundância.
1. CRM e Vendas: informação de contacto
Numa oportunidade CRM, o nome do cliente, telefone e email resultam do registo de parceiro ligado por Many2one. Se os dados do parceiro mudam, todas as oportunidades, cotações e encomendas que o referenciam refletem a alteração imediatamente.
Isto demonstra a combinação entre herança clássica e campos related: o CRM estende res.partner com campos específicos, e as vendas expõem info de contacto do parceiro por campos related.
2. Produtos e variantes
A gestão de variantes no Odoo usa delegação para separar template e variantes: product.product usa _inherits sobre product.template. Atributos comuns (nome, categoria, preço) ficam no template; detalhes por variante (referência interna, barcode) ficam no registo variante.
Assim, é possível ter dezenas de variantes de uma peça partilhando nome e descrição sem duplicar esses valores na base de dados.
3. Utilizadores e contactos
Cada utilizador corresponde também a um contacto. res.users usa _inherits = {'res.partner': 'partner_id'}, herdando campos como nome, email, telefone e morada. Alterações num email actualizam tanto as definições do utilizador como a ficha de contacto.
4. Inventário: movimentos e informação do produto
Linhas de movimento mostram descrições de produto que vêm do template através de campos relacionados. Os operadores veem informação actualizada nas listas de recolha sem que o módulo de inventário tenha de replicar dados do produto.
5. Contabilidade: linhas de fatura
Linhas de movimentos contabilísticos referenciam produtos e parceiros. Nome do produto, contas e impostos exibidos numa fatura vêm dos modelos de produto e parceiro via relações e campos related, garantindo consistência com a configuração feita pela equipa de vendas.
Criar ou personalizar campos herdados
Usar o Odoo Studio
O Odoo Studio é a interface sem código para personalizar modelos e vistas. Através do Studio pode adicionar-se campos a qualquer modelo sem escrever Python; em termos técnicos, o Studio aplica herança clássica e altera a definição do modelo.
O Studio também permite criar campos related. Ao escolher "Related Field" pode apontar-se para qualquer campo acessível por uma cadeia relacional. Por exemplo, na encomenda de venda cria-se um campo que puxa o país ou o número de IVA do parceiro.
Para muitos utilizadores e consultores funcionais, o Studio é o caminho mais prático: trata nomes, migração de base de dados e posicionamento nas vistas automaticamente.
Personalização técnica em Python
Para desenvolvedores que criam módulos, os campos herdados definem-se em Python com a classe models.Model do ORM do Odoo.
Herança clássica para adicionar um campo a um modelo existente:
class CrmLead(models.Model):
_inherit = 'crm.lead'
x_contract_value = fields.Float(
string='Estimated Contract Value'
)Herança por delegação para criar um modelo novo que partilha campos de outro:
class EmployeeProfile(models.Model):
_name = 'hr.employee.profile'
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one(
'res.partner',
required=True,
ondelete='cascade'
)
employee_id = fields.Many2one(
'hr.employee',
string='Employee'
)Campos related para expor valores de um registo ligado:
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Customer Country',
store=True
)Via API XML-RPC (configuração remota)
Também é possível criar campos programaticamente através da API XML-RPC do Odoo, manipulando o modelo ir.model.fields. Esta abordagem, usada em configurações remotas automatizadas, replica o que o Studio faz, permitindo criar campos sem acesso directo ao servidor.
Para criar um campo related via API, cria-se um registo em ir.model.fields com ttype apropriado e define-se o parâmetro related para a cadeia relacional. Isto encaixa bem em processos de deployment automatizado.
Boas práticas
Escolha o tipo de herança adequado
Use herança clássica quando apenas pretende adicionar campos ou métodos a um modelo existente — é simples e é a maioria dos casos. Reserve delegação para quando precisar de manter dois conjuntos de registos ligados, por exemplo quando um conceito de negócio estende um contacto mas não é exactamente um contacto por si só.
Prefira campos related para leitura
Se só necessita mostrar um valor ligado num formulário ou lista, um campo related é mais simples do que criar herança por delegação. Evita dependências estruturais desnecessárias e é mais fácil de manter.
Cuidado com store=True nos campos related
Armazenar um campo related acelera pesquisas e filtros, mas transforma o valor numa cópia. Odoo recomputa quando a fonte muda, mas em cenários marginais pode haver dessincronização. Guarde related fields apenas quando realmente precisar de filtrar ou agrupar em larga escala.
Prefixe sempre campos personalizados com x_
Qualquer campo que acrescente a um modelo padrão deveria começar por x_ (ou usar o namespace do módulo). Isto evita conflitos com campos que possam ser introduzidos pelo Odoo em versões futuras.
Documente a cadeia de heranças
Em personalizações complexas, registe brevemente onde cada campo vem e porquê. Um campo chamado x_country_code numa encomenda nem sempre remete de forma óbvia para partner_id.country_id.code sem uma nota explicativa.
Trate correctamente eliminações em cascata
Na herança por delegação, o registo pai costuma ser criado automaticamente com o filho. Ao apagar o filho pretende-se normalmente apagar também o pai. Defina ondelete='cascade' no Many2one usado em _inherits para evitar registos órfãos.
Erros comuns
Confundir os três tipos de herança
O erro mais frequente de quem começa é usar _inherit com _name quando queria apenas estender o modelo — o que cria inadvertidamente um novo modelo. Revise a definição: se não pretende um novo modelo, não declare _name.
Esquecer de criar o registo pai no _inherits
Na delegação, o registo pai nem sempre se cria sozinho em todas as situações, especialmente em chamadas API ou scripts. Ao criar um filho programaticamente, deixe o ORM criar o pai via create ou crie o pai primeiro e passe o seu ID; caso contrário ocorrerá um erro de constraint na base de dados.
Tentar mudar o tipo de um campo através da herança
Odoo não permite alterar o tipo de um campo existente via herança. Pode ajustar atributos como rótulo, domínio ou descrição, mas não transformar um Char em Integer. Tentar isso provoca erro na instalação do módulo.
Abusar de related fields armazenados
Adicionar store=True a todos os related fields pode parecer uma otimização, mas infla a base de dados e aumenta a manutenção. Se a fonte muda com frequência, esses campos disparam muita recomputação. Use-os pontualmente quando houver necessidade real de filtrar ou agrupar grandes volumes.
Assumir que campos herdados respeitam regras de acesso do filho
Campos herdados por delegação residem no modelo pai. As regras de acesso aplicadas ao filho não se propagam automaticamente ao nível da base de dados para o pai. Se restringir o acesso ao filho mas não ao pai, utilizadores podem aceder aos valores herdados através do modelo pai. Reveja sempre as regras de segurança de ambos os modelos quando usar delegação.
Conclusão
Os campos herdados não são uma funcionalidade marginal: estão integrados na arquitectura do Odoo. Relações como utilizadores–parceiros, variantes–templates e encomendas–contactos dependem dessa lógica para manter a coerência e evitar duplicação.
Saber qual o tipo de herança a escolher, quando usar um campo related e como o comportamento se traduz na base de dados torna-o um personalizador Odoo mais eficaz. Vai produzir modelos mais limpos, menos bugs e menos tempo perdido em debugging.
A conclusão é directa: o ORM do Odoo foi desenhado para que os campos vivam num só lugar e sejam acedidos a partir de muitos pontos. Esse princípio é a base dos campos herdados e mantém o modelo de dados consistente à medida que o sistema cresce.
Precisa de ajuda com a sua implementação Odoo?
Na Dasolo, ajudamos empresas a implementar, personalizar e optimizar Odoo. Seja para criar um módulo à medida, acrescentar campos a modelos padrão ou esclarecer comportamentos estranhos no seu modelo de dados, a nossa equipa tem experiência prática para o ajudar a avançar mais depressa e com menos riscos.
Se tiver dúvidas sobre o seu modelo de dados Odoo, estratégia de campos personalizados ou implementação técnica, teremos todo o gosto em analisar o seu caso. Contacte-nos e encontraremos a abordagem adequada para o seu projecto.