Pubblicare un modulo sull'Odoo App Store: le regole scritte e quelle che si imparano dopo 117 pubblicazioni

L'Odoo App Store è l'unico canale in cui un modulo di Odoo si vende senza un commerciale: qualcuno lo cerca, lo compra e lo installa. Pubblicare è gratis e chiunque può farlo con un repository git e un manifest scritto bene. Quello che non è scritto da nessuna parte è perché una pubblicazione impiega giorni ad apparire, perché una descrizione esce rotta o perché un modulo che compila sulla tua macchina non si installa nell'Odoo dell'acquirente. Questo è ciò che abbiamo imparato pubblicando 105 moduli e mantenendoli in Odoo 19, 18 e 17.

Le regole scritte: repository, branch e manifest

Il meccanismo è semplice e conviene rispettarlo alla lettera. Registri un repository git nel tuo account di apps.odoo.com; l'App Store lo scansiona e pubblica ogni modulo che vi trova. Il branch conta: il branch 19.0 alimenta le schede di Odoo 19, il 18.0 quelle di 18, il 17.0 quelle di 17. Lo stesso nome tecnico nei tre branch è una sola scheda con tre versioni, ed è quello che vuoi: un URL, una pagina di recensioni, tre pulsanti di download. Nomi tecnici diversi per versione sono tre schede che si spartiscono le visite.

Del manifest, ciò che l'App Store legge e mostra:

• name, summary e category: il titolo della scheda, la riga sotto e dove compare nel catalogo. Il nome deve essere unico in tutto lo store.
• version con il prefisso della versione di Odoo (19.0.1.0.0): senza quel prefisso la scheda non sa a quale Odoo appartiene.
• license: OPL-1 per i moduli a pagamento, LGPL-3 o AGPL-3 per quelli gratuiti. Un modulo a pagamento con licenza libera è un regalo che non volevi fare.
• price e currency: il prezzo della scheda. Odoo trattiene una parte di ogni vendita e ti liquida il resto; la proporzione è pubblicata nelle condizioni dell'App Store.
• images: l'elenco delle schermate, a partire dal banner che si vede nel catalogo. Senza banner, la scheda esce con un vuoto grigio accanto a quelle che ce l'hanno.
• static/description/index.html: la descrizione lunga. HTML senza script, immagini relative dentro il modulo e, per esperienza, caratteri ASCII: un accento o delle virgolette tipografiche codificati male possono lasciare la scheda con simboli rotti che non vedi finché non è pubblicata.

Le regole che non sono scritte

Comanda la nuova scansione, e non si forza con uno zip

Dopo un push, la scheda non cambia all'istante: l'App Store scansiona di nuovo il repository con il suo ritmo, che può essere di ore o di giorni. La tentazione è caricare uno zip a mano per «accelerare». Non farlo: una versione caricata a mano e una versione scansionata dal repository convivono male, e finisci con una scheda di cui non sai da dove arrivi. La regola che seguiamo è una sola fonte, il repository, e pazienza. Se ti serve che la scansione si accorga di una modifica, alza il numero di versione del manifest: una modifica al contenuto con la stessa versione a volte non viene recepita.

Compilare non è installare

La scansione non installa il modulo. Che il manifest sia valido e il codice si importi senza errori non significa che il modulo si installi. In Odoo 19 questo è diventato particolarmente insidioso: i gruppi di sicurezza hanno cambiato modello (res.groups.privilege), ir.cron non ammette più il campo numbercall, e le viste elenco si chiamano list, non tree. Un modulo scritto per la 17 supera la scansione della 19 senza lamentele e fallisce in installazione nell'Odoo dell'acquirente. Lo spieghiamo nel dettaglio in perché un modulo di Odoo 19 compila ma non si installa.

Tre versioni sono tre moduli che si somigliano

Mantenere lo stesso modulo in 19, 18 e 17 non significa copiare la cartella in tre branch. Ogni versione ha le sue differenze di API, e l'unico modo per sapere che tutte e tre funzionano è installarle su un Odoo reale di ciascuna versione. Noi lo facciamo su Odoo.sh: una build per versione, installazione pulita, test e solo allora il push al branch che l'App Store scansiona. E con Odoo 20, uscito a settembre 2026, il processo è lo stesso con un branch in più. Un modulo provato solo nella versione in cui è stato scritto è un modulo che si venderà tre volte e fallirà due.

Il processo che seguiamo, in ordine

1. Nome tecnico unico e definitivo. Si cerca nell'App Store prima di scrivere la prima riga; cambiarlo dopo significa perdere la scheda e le sue recensioni.
2. Manifest completo dal primo commit: versione con prefisso, licenza, prezzo, categoria, immagini, dipendenze esatte.
3. Installazione pulita su Odoo.sh reale di ogni versione che si vuole pubblicare, con i test in verde. Senza questo non c'è push.
4. Descrizione in ASCII con schermate reali del modulo installato, non mockup. L'acquirente confronta ciò che vede nella scheda con ciò che installa.
5. Push al branch di versione e attendere la scansione. Niente zip. Se bisogna correggere, si alza la versione e si aspetta di nuovo.
6. Controllare la scheda pubblicata nelle tre versioni: banner, descrizione senza simboli rotti, prezzo, pulsante di download.

Cosa non fa la pubblicazione al posto tuo

Pubblicare non è vendere. Una scheda fatta bene compare quando qualcuno cerca esattamente quel problema, e basta. Ciò che fa sì che venga installato è che il modulo funzioni al primo colpo, che la descrizione dica cosa fa e cosa no, e che le domande di supporto ricevano risposta. Per questo trattiamo ogni modulo pubblicato come un prodotto con la sua manutenzione, non come un file caricato. E per questo, quando un'azienda di software ci chiede un connettore per il suo prodotto, la pubblicazione sull'App Store fa parte del lavoro, non è un extra: è dove i suoi utenti di Odoo andranno a cercarlo.

Domande frequenti

Link utili all'interno di FlexigoTech