Publicar un mòdul a l'Odoo App Store: les regles escrites i les que s'aprenen després de 117 publicacions

L'Odoo App Store és l'únic canal on un mòdul d'Odoo es ven sense comercial: algú el busca, el compra i l'instal·la. Publicar és gratis i qualsevol pot fer-ho amb un repositori git i un manifest ben escrit. El que no està escrit enlloc és per què una publicació triga dies a aparèixer, per què una descripció surt trencada, o per què un mòdul que compila a la teva màquina no s'instal·la a l'Odoo del comprador. Això és el que hem après publicant 105 mòduls i mantenint-los a Odoo 19, 18 i 17.

Les regles escrites: repositori, branca i manifest

El mecanisme és simple i convé respectar-lo al peu de la lletra. Dones d'alta un repositori git al teu compte d'apps.odoo.com; l'App Store l'escaneja i publica cada mòdul que hi trobi. La branca importa: la branca 19.0 alimenta les fitxes d'Odoo 19, la 18.0 les de 18, la 17.0 les de 17. Un mateix nom tècnic a les tres branques és una sola fitxa amb tres versions, i això és el que vols: una URL, una pàgina de ressenyes, tres botons de descàrrega. Noms tècnics diferents per versió són tres fitxes que es reparteixen les visites.

Del manifest, el que l'App Store llegeix i mostra:

• name, summary i category: el títol de la fitxa, la línia de sota i on apareix al catàleg. El nom ha de ser únic a tota la botiga.
• version amb el prefix de la versió d'Odoo (19.0.1.0.0): sense aquest prefix la fitxa no sap a quin Odoo pertany.
• license: OPL-1 per a mòduls de pagament, LGPL-3 o AGPL-3 per als gratuïts. Un mòdul de pagament amb llicència lliure és un regal que no volies fer.
• price i currency: el preu de la fitxa. Odoo es queda una part de cada venda i et liquida la resta; la proporció està publicada a les condicions de l'App Store.
• images: la llista de captures, començant pel bàner que es veu al catàleg. Sense bàner, la fitxa surt amb un buit gris al costat de les que sí que en tenen.
• static/description/index.html: la descripció llarga. HTML sense scripts, imatges relatives dins del mòdul i, per experiència, caràcters ASCII: un accent o unes cometes tipogràfiques mal codificats poden deixar la fitxa amb símbols trencats que no veus fins que està publicada.

Les regles que no estan escrites

El re-escaneig mana, i no es força amb un zip

Després d'un push, la fitxa no canvia a l'instant: l'App Store torna a escanejar el repositori amb el seu propi ritme, que pot ser d'hores o de dies. La temptació és pujar un zip a mà per «accelerar». No ho facis: una versió pujada a mà i una versió escanejada del repositori conviuen malament, i acabes amb una fitxa de la qual no saps d'on surt. La regla que seguim és una sola font, el repositori, i paciència. Si necessites que l'escaneig es fixi en un canvi, puja el número de versió del manifest: un canvi en el contingut amb la mateixa versió a vegades no es recull.

Compilar no és instal·lar

L'escaneig no instal·la el mòdul. Que el manifest sigui vàlid i el codi importi sense errors no vol dir que el mòdul s'instal·li. A Odoo 19 això s'ha tornat especialment traïdor: els grups de seguretat han canviat de model (res.groups.privilege), ir.cron ja no admet el camp numbercall, i les vistes de llista es diuen list, no tree. Un mòdul escrit per a la 17 passa l'escaneig de la 19 sense queixa i falla en instal·lar-se a l'Odoo del comprador. Ho detallem a per què un mòdul d'Odoo 19 compila però no s'instal·la.

Tres versions són tres mòduls que s'assemblen

Mantenir el mateix mòdul a 19, 18 i 17 no és copiar la carpeta a tres branques. Cada versió té les seves diferències d'API, i l'única manera de saber que les tres funcionen és instal·lar-les en un Odoo real de cada versió. Nosaltres ho fem sobre Odoo.sh: una build per versió, instal·lació neta, tests, i només llavors el push a la branca que l'App Store escaneja. I amb Odoo 20, que va sortir el setembre de 2026, el procés és el mateix amb una branca més. Un mòdul que només s'ha provat a la versió en què es va escriure és un mòdul que es vendrà tres vegades i fallarà dues.

El procés que seguim, per ordre

1. Nom tècnic únic i definitiu. Es busca a l'App Store abans d'escriure la primera línia; canviar-lo després és perdre la fitxa i les seves ressenyes.
2. Manifest complet des del primer commit: versió amb prefix, llicència, preu, categoria, imatges, dependències exactes.
3. Instal·lació neta en Odoo.sh real de cada versió que es publicarà, amb els tests en verd. Sense això no hi ha push.
4. Descripció en ASCII amb captures reals del mòdul instal·lat, no maquetes. El comprador compara el que veu a la fitxa amb el que instal·la.
5. Push a la branca de versió i esperar l'escaneig. Res de zips. Si cal corregir, es puja la versió i es torna a esperar.
6. Comprovar la fitxa publicada a les tres versions: bàner, descripció sense símbols trencats, preu, botó de descàrrega.

El que la publicació no fa per tu

Publicar no és vendre. Una fitxa ben feta apareix quan algú busca exactament aquest problema, i això és tot. El que fa que s'instal·li és que el mòdul funcioni a la primera, que la descripció digui el que fa i el que no, i que les preguntes de suport es responguin. Per això tractem cada mòdul publicat com un producte amb el seu manteniment, no com un fitxer pujat. I per això, quan una empresa de programari ens demana un connector per al seu producte, la publicació a l'App Store és part de la feina, no un extra: és on els seus usuaris d'Odoo el aniran a buscar.

Preguntes freqüents

Enllaços útils dins de FlexigoTech