Publicar um módulo na Odoo App Store: as regras escritas e as que se aprendem depois de 117 publicações

A Odoo App Store é o único canal onde um módulo de Odoo se vende sem comercial: alguém procura-o, compra-o e instala-o. Publicar é gratuito e qualquer pessoa pode fazê-lo com um repositório git e um manifest bem escrito. O que não está escrito em lado nenhum é porque é que uma publicação demora dias a aparecer, porque é que uma descrição sai estragada, ou porque é que um módulo que compila na sua máquina não se instala no Odoo do comprador. Isto é o que aprendemos a publicar 105 módulos e a mantê-los no Odoo 19, 18 e 17.

As regras escritas: repositório, ramo e manifest

O mecanismo é simples e convém respeitá-lo à letra. Regista um repositório git na sua conta de apps.odoo.com; a App Store analisa-o e publica cada módulo que encontrar nele. O ramo importa: o ramo 19.0 alimenta as fichas do Odoo 19, o 18.0 as do 18, o 17.0 as do 17. Um mesmo nome técnico nos três ramos é uma única ficha com três versões, e é isso que quer: um URL, uma página de avaliações, três botões de descarga. Nomes técnicos diferentes por versão são três fichas que repartem as visitas.

Do manifest, o que a App Store lê e mostra:

• name, summary e category: o título da ficha, a linha por baixo e onde aparece no catálogo. O nome tem de ser único em toda a loja.
• version com o prefixo da versão do Odoo (19.0.1.0.0): sem esse prefixo a ficha não sabe a que Odoo pertence.
• license: OPL-1 para módulos pagos, LGPL-3 ou AGPL-3 para os gratuitos. Um módulo pago com licença livre é uma oferta que não queria fazer.
• price e currency: o preço da ficha. A Odoo fica com uma parte de cada venda e paga-lhe o resto; a proporção está publicada nas condições da App Store.
• images: a lista de capturas, começando pelo banner que se vê no catálogo. Sem banner, a ficha aparece com um espaço cinzento ao lado das que o têm.
• static/description/index.html: a descrição longa. HTML sem scripts, imagens relativas dentro do módulo e, por experiência, caracteres ASCII: um acento ou umas aspas tipográficas mal codificados podem deixar a ficha com símbolos estragados que só vê depois de publicada.

As regras que não estão escritas

O re-scan manda, e não se força com um zip

Depois de um push, a ficha não muda de imediato: a App Store volta a analisar o repositório ao seu próprio ritmo, que pode ser de horas ou de dias. A tentação é carregar um zip à mão para «acelerar». Não o faça: uma versão carregada à mão e uma versão analisada do repositório convivem mal, e acaba com uma ficha cuja origem desconhece. A regra que seguimos é uma só fonte, o repositório, e paciência. Se precisar que a análise repare numa alteração, suba o número de versão do manifest: uma alteração de conteúdo com a mesma versão às vezes não é recolhida.

Compilar não é instalar

A análise não instala o módulo. Que o manifest seja válido e o código importe sem erros não significa que o módulo se instale. No Odoo 19 isto tornou-se especialmente traiçoeiro: os grupos de segurança mudaram de modelo (res.groups.privilege), ir.cron já não admite o campo numbercall, e as vistas de lista chamam-se list, não tree. Um módulo escrito para o 17 passa a análise do 19 sem queixas e falha ao instalar no Odoo do comprador. Detalhamo-lo em porque é que um módulo de Odoo 19 compila mas não se instala.

Três versões são três módulos parecidos

Manter o mesmo módulo no 19, 18 e 17 não é copiar a pasta para três ramos. Cada versão tem as suas diferenças de API, e a única maneira de saber que as três funcionam é instalá-las num Odoo real de cada versão. Nós fazemo-lo no Odoo.sh: uma build por versão, instalação limpa, testes, e só então o push para o ramo que a App Store analisa. E com o Odoo 20, que saiu em setembro de 2026, o processo é o mesmo com mais um ramo. Um módulo testado apenas na versão em que foi escrito é um módulo que se venderá três vezes e falhará duas.

O processo que seguimos, por ordem

1. Nome técnico único e definitivo. Procura-se na App Store antes de escrever a primeira linha; mudá-lo depois é perder a ficha e as suas avaliações.
2. Manifest completo desde o primeiro commit: versão com prefixo, licença, preço, categoria, imagens, dependências exatas.
3. Instalação limpa em Odoo.sh real de cada versão que se vai publicar, com os testes em verde. Sem isto não há push.
4. Descrição em ASCII com capturas reais do módulo instalado, não maquetes. O comprador compara o que vê na ficha com o que instala.
5. Push para o ramo da versão e esperar pela análise. Nada de zips. Se for preciso corrigir, sobe-se a versão e volta-se a esperar.
6. Verificar a ficha publicada nas três versões: banner, descrição sem símbolos estragados, preço, botão de descarga.

O que a publicação não faz por si

Publicar não é vender. Uma ficha bem feita aparece quando alguém procura exatamente esse problema, e é tudo. O que faz com que se instale é que o módulo funcione à primeira, que a descrição diga o que faz e o que não faz, e que as perguntas de suporte sejam respondidas. Por isso tratamos cada módulo publicado como um produto com a sua manutenção, não como um ficheiro carregado. E por isso, quando uma empresa de software nos pede um conector para o seu produto, a publicação na App Store faz parte do trabalho, não é um extra: é onde os seus utilizadores de Odoo o vão procurar.

Perguntas frequentes

Ligações úteis dentro da FlexigoTech