Publicar un módulo en la Odoo App Store: las reglas escritas y las que se aprenden después de 117 publicaciones

La Odoo App Store es el único canal donde un módulo de Odoo se vende sin comercial: alguien lo busca, lo compra y lo instala. Publicar es gratis y cualquiera puede hacerlo con un repositorio git y un manifest bien escrito. Lo que no está escrito en ningún sitio es por qué una publicación tarda días en aparecer, por qué una descripción sale rota, o por qué un módulo que compila en tu máquina no se instala en el Odoo del comprador. Esto es lo que hemos aprendido publicando 117 módulos y manteniéndolos en Odoo 19, 18 y 17.

Las reglas escritas: repositorio, rama y manifest

El mecanismo es simple y conviene respetarlo al pie de la letra. Das de alta un repositorio git en tu cuenta de apps.odoo.com; el App Store lo escanea y publica cada módulo que encuentre en él. La rama importa: la rama 19.0 alimenta las fichas de Odoo 19, la 18.0 las de 18, la 17.0 las de 17. Un mismo nombre técnico en las tres ramas es una sola ficha con tres versiones, y eso es lo que quieres: una URL, una página de reseñas, tres botones de descarga. Nombres técnicos distintos por versión son tres fichas que se reparten las visitas.

Del manifest, lo que el App Store lee y muestra:

• name, summary y category: el título de la ficha, la línea de debajo y dónde aparece en el catálogo. El nombre debe ser único en toda la tienda.
• version con el prefijo de la versión de Odoo (19.0.1.0.0): sin ese prefijo la ficha no sabe a qué Odoo pertenece.
• license: OPL-1 para módulos de pago, LGPL-3 o AGPL-3 para los gratuitos. Un módulo de pago con licencia libre es un regalo que no querías hacer.
• price y currency: el precio de la ficha. Odoo se queda una parte de cada venta y te liquida el resto; la proporción está publicada en las condiciones del App Store.
• images: la lista de capturas, empezando por el banner que se ve en el catálogo. Sin banner, la ficha sale con un hueco gris al lado de las que sí lo tienen.
• static/description/index.html: la descripción larga. HTML sin scripts, imágenes relativas dentro del módulo, y, por experiencia, caracteres ASCII: una tilde o unas comillas tipográficas mal codificadas pueden dejar la ficha con símbolos rotos que no ves hasta que está publicada.

Las reglas que no están escritas

El re-escaneo manda, y no se fuerza con un zip

Después de un push, la ficha no cambia al instante: el App Store vuelve a escanear el repositorio con su propio ritmo, que puede ser de horas o de días. La tentación es subir un zip a mano para «acelerar». No lo hagas: una versión subida a mano y una versión escaneada del repositorio conviven mal, y acabas con una ficha que no sabes de dónde sale. La regla que seguimos es una sola fuente, el repositorio, y paciencia. Si necesitas que el escaneo se fije en un cambio, sube el número de versión del manifest: un cambio en el contenido con la misma versión a veces no se recoge.

Compilar no es instalar

El escaneo no instala el módulo. Que el manifest sea válido y el código importe sin errores no significa que el módulo se instale. En Odoo 19 esto se ha vuelto especialmente traicionero: los grupos de seguridad han cambiado de modelo (res.groups.privilege), ir.cron ya no admite el campo numbercall, y las vistas de lista se llaman list, no tree. Un módulo escrito para la 17 pasa el escaneo de la 19 sin queja y falla al instalar en el Odoo del comprador. Lo detallamos en por qué un módulo de Odoo 19 compila pero no se instala.

Tres versiones son tres módulos que se parecen

Mantener el mismo módulo en 19, 18 y 17 no es copiar la carpeta a tres ramas. Cada versión tiene sus diferencias de API, y la única manera de saber que las tres funcionan es instalarlas en un Odoo real de cada versión. Nosotros lo hacemos sobre Odoo.sh: una build por versión, instalación limpia, tests, y solo entonces el push a la rama que el App Store escanea. Y cuando salga Odoo 20, el proceso es el mismo con una rama más. Un módulo que solo se ha probado en la versión en la que se escribió es un módulo que se venderá tres veces y fallará dos.

El proceso que seguimos, en orden

1. Nombre técnico único y definitivo. Se busca en el App Store antes de escribir la primera línea; cambiarlo después es perder la ficha y sus reseñas.
2. Manifest completo desde el primer commit: versión con prefijo, licencia, precio, categoría, imágenes, dependencias exactas.
3. Instalación limpia en Odoo.sh real de cada versión que se va a publicar, con los tests en verde. Sin esto no hay push.
4. Descripción en ASCII con capturas reales del módulo instalado, no maquetas. El comprador compara lo que ve en la ficha con lo que instala.
5. Push a la rama de versión y esperar el escaneo. Nada de zips. Si hay que corregir, se sube la versión y se vuelve a esperar.
6. Comprobar la ficha publicada en las tres versiones: banner, descripción sin símbolos rotos, precio, botón de descarga.

Lo que la publicación no hace por ti

Publicar no es vender. Una ficha bien hecha aparece cuando alguien busca exactamente ese problema, y eso es todo. Lo que hace que se instale es que el módulo funcione a la primera, que la descripción diga lo que hace y lo que no, y que las preguntas de soporte se contesten. Por eso tratamos cada módulo publicado como un producto con su mantenimiento, no como un fichero subido. Y por eso, cuando una empresa de software nos pide un conector para su producto, la publicación en el App Store es parte del trabajo, no un extra: es donde sus usuarios de Odoo lo van a buscar.

Preguntas frecuentes

Enlaces útiles dentro de FlexigoTech