Odoo 20, overview tecnica: cosa cambia davvero se sei su Odoo 17 o 18

Odoo 20 è stata rilasciata l'11 settembre 2026 nel repository ufficiale di Odoo. Come a ogni release, nelle settimane successive circolano elenchi di funzionalità: utili per farsi un'idea, inutili per decidere.

Noi abbiamo fatto una cosa diversa. Abbiamo clonato i repository di Odoo 19 e Odoo 20 — Community ed Enterprise — e abbiamo iniziato a testare con mano le funzionalità introdotte, insieme alle migliorie apportate a ciò che già conoscevamo.

Questo articolo non elenca tutto. Isola le cose che, se gestisci un'installazione Odoo con delle personalizzazioni sopra, cambiano il conto del preventivo di migrazione o la data in cui conviene farla.

Odoo 20 in sintesi: AI, AI, E ANCORA AI.

1. L'AI smette di suggerire e comincia a fare

L'AI in Odoo non nasce con la 20: la 19 aveva già quindici moduli ai_* — l'assistente nel CRM, nella Knowledge Base, nei campi calcolati, nel livechat. Erano strumenti di supporto: suggerivano un testo, riassumevano un documento, rispondevano a un cliente.

Nella 20 i moduli ai_* in Enterprise diventano cinquantuno, e il salto non è di quantità. Il modulo chiave si chiama ai_agentic e introduce due concetti che prima non c'erano:

• ai.skill — un'abilità configurabile fatta di istruzioni più un insieme di strumenti
• gli strumenti sono ir.actions.server con il flag use_in_ai attivo.

Detto senza giri: un agente AI in Odoo 20 può eseguire azioni server sul tuo database. Non scrive una bozza di email da approvare — crea il record, cambia lo stato, lancia il workflow. Il modulo dipende da base_automation, quindi gli agenti si agganciano alle automazioni esistenti.

Accanto c'è ai_mcp, il modulo per l'integrazione MCP: Odoo espone un server MCP — il Model Context Protocol, lo standard con cui gli assistenti AI si collegano a sistemi esterni. L'indirizzo è l'URL della tua istanza con il suffisso /mcp, l'autenticazione avviene con una API key di scope MCP, e il modulo implementa un server OAuth completo (client registrati, authorization code, bearer token su rotta protetta). Significa che un client AI esterno può interrogare e operare sul gestionale attraverso un canale autenticato e tracciato.

Poi ci sono i bridge verticali, uno per applicazione: ai_sale, ai_purchase, ai_stock, ai_project, ai_timesheet_grid, ai_account_reports, ai_helpdesk, ai_product, ai_mass_mailing, l'intera famiglia ai_marketing_automation (CRM, SMS, WhatsApp, loyalty, e-commerce), ai_html_builder, ai_calendar, ai_esg.

La cautela che va detta subito. Tutti questi moduli sono marcati iap_paid_service e licenza OEEL-1: sono Enterprise, a consumo, e il ragionamento avviene su modelli linguistici esterni. Prima di accendere un agente con permessi di scrittura su un gestionale in produzione vanno decise tre cose — quali dati escono, con quali permessi gira l'agente, e chi controlla cosa ha fatto (vedi note sulla sicurezza e privacy dei dati nella sezione successiva). Sono domande di governance, non di configurazione, e la risposta non è nel manuale.

Va poi detto che, vista la forte domanda che ha caratterizzato l'implementazione di tool AI, l'integrazione tra Odoo e server MCP (così come la parte agentica) è stata già affrontata da compagnie implementatrici e clienti in maniera autonoma. Per molti clienti si tratterebbe quindi di scegliere se migrare gli strumenti già implementati alle app native di Odoo 20 o continuare a utilizzare ciò che già è testato, funzionante e su cui si sono spesi investimenti importanti.

Dove finiscono i dati dell'istanza

È la domanda che ci fanno tutti i clienti appena si nomina l'AI, e merita una risposta precisa invece che rassicurante. L'abbiamo cercata nel codice.

L'istanza non parla mai direttamente con le società di AI. Tutte le chiamate passano da un unico endpoint, https://ai.api.odoo.com, definito in ai/utils/ai_utils.py: è l'infrastruttura IAP di Odoo, e l'autenticazione avviene con il token dell'account più l'UUID del database. Non serve — e non si può impostare — una chiave API di OpenAI o Google: è Odoo a inoltrare la richiesta al fornitore del modello. Ai fini contrattuali la tua controparte è Odoo S.A., e il fornitore dell'LLM è un suo sub-responsabile.

Quale modello venga usato, nella 20 non lo decidi più tu. In Odoo 19 il modello ai.agent aveva un campo llm_model con cui si sceglieva l'LLM; nella 20 quel campo non esiste più e la selezione è passata lato server, dentro il proxy di Odoo. Nel codice restano riferimenti a Gemini e OpenAI come provider attivi.

Cosa esce davvero. Guardando i parametri della richiesta di completion, partono la conversazione, il system prompt con le istruzioni delle skill caricate, gli schemi degli strumenti esposti — e i risultati degli strumenti, cioè i dati letti dal database e rimandati al modello per il passo successivo. Non esce solo la domanda dell'utente: escono i record. Se l'agente legge tre fatture per rispondere, quelle tre fatture finiscono nel prompt successivo. Non esiste alcuna forma di anonimizzazione o mascheramento: i dati partono come sono.

Cosa fa Odoo per proteggerli. Le misure ci sono, sono nel codice e agiscono tutte a monte, cioè limitano cosa l'AI può leggere:

• una blocklist di modelli mai esposti all'AI (base.automation, res.device, res.groups, res.groups.privilege, res.users.settings, più i modelli interni ai.*): l'agente non può leggersi la configurazione della sicurezza
• l'agente eredita i permessi di chi lo usa, non di più: gli strumenti verificano l'accesso con check_access e has_access prima di leggere, e l'esecuzione delle azioni server fa una de-escalation esplicita ai diritti dell'utente reale. Un agente non vede quello che l'utente non vedrebbe
• conferma umana prima di agire: ogni chiamata a uno strumento che scrive si ferma e chiede conferma, con l'approvazione automatica disattivata per impostazione predefinita, e un tetto al numero di chiamate consecutive che impedisce a un agente di andare in loop.

I due punti su cui porre attenzione. Il primo riguarda MCP: quando la richiesta arriva da un client esterno, la conferma umana viene data per acquisita e lo strumento parte. Gli strumenti esposti via MCP hanno un flag dedicato, distinto da quello degli agenti interni, quindi la superficie si può restringere — ma chi possiede il token agisce con i pieni diritti di quell'utente, senza nessuno nel mezzo. Quel token va trattato come una password, non come una chiave di sola lettura.

Il secondo è più sottile: la superficie dei dati che possono uscire coincide con il set di permessi dell'utente che usa l'agente. Se lo usa qualcuno che può leggere tutte le fatture, potenzialmente tutte le fatture possono uscire. Il controllo vero non è una spunta nelle impostazioni, è il disegno dei gruppi e delle record rules — che nella maggior parte delle installazioni non è mai stato riletto con questa domanda in testa.

Resta un ultimo aspetto che nel codice non si trova, perché non è tecnico: conservazione dei dati, utilizzo per l'addestramento, residenza ed elenco dei sub-responsabili sono materia contrattuale, e stanno nell'accordo sul trattamento dei dati di Odoo. Ai fini GDPR il titolare resta l'azienda cliente, Odoo è responsabile del trattamento e il fornitore del modello è sub-responsabile. Per un cliente che tratta dati sanitari, giudiziari o soggetti a vincoli di riservatezza, quel documento è la prima cosa da leggere — prima ancora di installare il modulo.

2. Paper Muncher: finisce l'era di wkhtmltopdf (finalmente)

Chiunque abbia messo mano ai report PDF di Odoo conosce wkhtmltopdf: il binario esterno, la versione patchata da installare a mano, i margini che si comportano in modo strano, il CSS moderno che non viene reso perché il motore sotto è un WebKit fermo a dieci anni fa.

Odoo 20 introduce Paper Muncher, un motore di rendering HTML→PDF scritto internamente da Odoo. Sta nel modulo base_report_paper_muncher e aggiunge un nuovo tipo di report, qweb-pdf-paper-muncher, accanto a quelli esistenti. Gestisce header e footer in modo nativo e legge i parametri di paperformat (DPI, margini) direttamente.

wkhtmltopdf non sparisce: è stato scorporato nel modulo base_report_wkhtmltox, installato automaticamente. Le due strade convivono.

Cosa comporta in pratica. Se hai report personalizzati — e se sei un'azienda italiana con DDT, fatture accompagnatorie o layout concordati con il commercialista, li hai — il passaggio al nuovo motore va testato documento per documento. Un motore di rendering diverso rende il CSS in modo diverso: è esattamente il tipo di lavoro che non si stima a occhio e che va messo a preventivo. La buona notizia è che si può migrare un report alla volta, perché il tipo di report è un campo del singolo ir.actions.report.

3. ir.access: un solo modello per permessi e regole

Questa è la modifica che tocca ogni modulo personalizzato esistente, senza eccezioni.

Da sempre in Odoo la sicurezza si scrive in due posti: ir.model.access (il file ir.model.access.csv, con le quattro colonne perm_read, perm_write, perm_create, perm_unlink) e ir.rule (le record rules, in XML, con i domini). Due modelli, due sintassi, due punti in cui guardare quando un utente vede quello che non dovrebbe.

Odoo 20 li fonde in un modello unico, ir.access, e in un unico file security/ir.access.csv. Il formato cambia così:

# Odoo 19 — ir.model.access.csv
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_account_account_salesman,...,account.model_account_account,sales_team.group_sale_salesman,1,0,0,0

# Odoo 20 — ir.access.csv
id,name,model_id,group_id/id,operation,domain
access_account_account_salesman,...,account.account,sales_team.group_sale_salesman,r,

I permessi diventano una stringa CRUD (r, cru, crud…), il dominio è una colonna della stessa riga, e ogni regola è classificata come permission o restriction. Il dominio guadagna anche un operatore nuovo — ('move_id', 'access', 'read') — che permette di far dipendere l'accesso a un record dall'accesso a un altro, cosa che prima richiedeva codice.

Il risultato, una volta arrivati dall'altra parte, è più pulito: la sicurezza di un modello si legge in un posto solo. Il percorso per arrivarci, però, passa da tutti i file di sicurezza di tutti i moduli custom.

Odoo fornisce uno script di conversione automatica — 19.4-00-ir-access.py, eseguibile con il comando odoo upgrade_code — che riscrive i CSV e gli XML delle record rules. Funziona bene sui casi standard. Non funziona sulle regole costruite in Python a runtime, che vanno riviste a mano.

Il server: requisiti minimi più alti

Un dettaglio che si scopre tardi e costa mezza giornata, quindi meglio dirlo prima. I requisiti minimi dichiarati in odoo/release.py cambiano:

	Odoo 19	Odoo 20
Python	3.10	3.12
PostgreSQL	13	16

Cambiano anche alcune dipendenze Python: PyPDF2 è sostituito da pypdf, spariscono pytz e xlwt dalle dipendenze dichiarate, entra h11.

La conseguenza pratica è che una macchina con Ubuntu 22.04 — Python 3.10, PostgreSQL 14 dai repository di sistema — non è più sufficiente. Serve Ubuntu 24.04 o Debian 13, e se il database sta su un server gestito da altri il salto di PostgreSQL va concordato e pianificato prima, non durante la migrazione.

Cosa si rompe nel codice personalizzato

Oltre a ir.access, il ramo 20.0 porta una serie di modifiche che toccano il codice custom. Le più rilevanti:

• OWL 3. Il framework frontend passa alla versione 3: t-ref diventa un sistema a signals, i props si leggono con useProps, onWillUpdateProps viene sostituito, i static defaultProps sono vietati dal livello di compatibilità. Ogni componente JavaScript scritto su misura va rivisto. Odoo distribuisce uno script di migrazione (owl3-migration.py), che fa la parte meccanica.
• registry.clear_cache diventa transaction.invalidate_ormcache.
• _rec_names_search deve essere una tupla, non una lista.
• Negli XML, type="base64" diventa type="bytes" per i file allegati.
• t-call nei template QWeb cambia gestione e ha il suo script di conversione.

Va detto che Odoo ha fatto un buon lavoro sugli strumenti: la directory odoo/upgrade_code/ contiene script di conversione per quasi tutte queste modifiche, e si lanciano con un comando. Il tempo che restituiscono è reale. Il tempo che non restituiscono è quello del test: nessuno script ti dice se, dopo la conversione, il flusso di approvazione degli ordini funziona ancora come prima.

Moduli che cambiano casa

Alcuni riassetti valgono una verifica, perché toccano funzionalità che potresti avere attive:

• Field Service è stato riscritto. Spariscono industry_fsm* e helpdesk_fsm*; arriva una famiglia di quattordici moduli planning_field_service_*, costruita su Planning invece che su Project. Chi usa gli interventi sul campo non fa un aggiornamento: fa una nuova implementazione del modulo.
• L'IoT Box diventa Obox. Sparisce iot_box_image, arriva la famiglia obox_* (con versioni Android per POS e Quality) e un modulo printer di base. Chi ha stampanti fiscali, bilance o terminali di pagamento collegati via IoT Box deve verificare la compatibilità dell'hardware prima di programmare la migrazione.
• Wishlist e comparazione prodotti entrano dentro website_sale: i moduli separati website_sale_wishlist e website_sale_comparison non esistono più.
• base_vat, base_iban, l10n_latam_base sono assorbiti nel core, così come stock_picking_batch. Meno moduli da installare, ma anche dipendenze da correggere nei manifest dei moduli custom che li richiamavano.
• Gli acquisti alternativi si scorporano da purchase_requisition in purchase_alternative e nei suoi bridge.

Novità funzionali che vale la pena conoscere

Senza pretesa di completezza, i moduli nuovi in Community che hanno un impatto commerciale diretto:

Modulo	Cosa fa
mysubscription	portale self-service in cui il cliente gestisce i propri abbonamenti
portal_discuss	Discuss aperto agli utenti portale: chat diretta con clienti e fornitori
crm_sale_project	conversione di un'opportunità direttamente in progetto
sale_project_margin	vista dei margini di progetto
fleet_maintenance	collega le attrezzature di Maintenance ai veicoli della flotta
pos_stock, pos_sale_stock	disponibilità di magazzino dentro il punto cassa
mail_tracking	il tracciamento email diventa un modulo separato dal core di mail
website_partnership	gestione dei partner sul sito
populate	generazione di dati sintetici per test e collaudi

Nello stock arriva inoltre un wizard di suggerimento dei punti di riordino, e il POS guadagna una lista lunga di integrazioni di pagamento e hardware nuove (Bancontact Pay, Mollie, Cashdro, Cashmatic, stampanti iMin, QRIS).

Sul fronte prestazioni, il diff contiene 228 commit [PERF] concentrati soprattutto su contabilità (indici nuovi su account.move, calcoli più rapidi degli importi, gestione della memoria nei pagamenti batch) e sul bus delle notifiche.

Per l'Italia: la localizzazione si consolida

Chi lavora con la fatturazione elettronica troverà l10n_it_edi in condizioni migliori. Nel diff ci sono una sessantina di commit sulla localizzazione italiana, quasi tutti correttivi su casi che in produzione fanno perdere tempo:

• import corretto di più fatture contenute in un unico XML
• gestione delle casse previdenziali, comprese più casse sulla stessa riga e quelle con aliquota a zero
• split payment: dati e logica di chiusura corretti
• regime forfettario: le fatture semplificate (TD07) si usano senza vincoli
• OSS reso conforme al tracciato FatturaPA
• assegnazione corretta del tipo documento TD01 in importazione
• VF25 corretto nella dichiarazione IVA annuale
• posizione fiscale applicata alle imposte delle fatture fornitore importate
• ritenuta RA Agenti su imponibile al 20%.

La novità funzionale è il CodiceCommessaConvenzione nelle fatture elettroniche, il campo richiesto nelle forniture verso la Pubblica Amministrazione legate a una commessa o convenzione.

Nessuna di queste è una funzionalità da brochure. Sono tutte cose che, se le hai incontrate, sai quanto costano.

Quando non migrare adesso

La risposta onesta è che, come ad ogni rilascio di una nuova versione Odoo, per la maggior parte delle aziende la migrazione a Odoo 20 non è una cosa da fare questo trimestre (e probabilmente neanche nel primo del 2027).

Rimanda se hai molti moduli personalizzati con componenti OWL e report PDF su misura: fra OWL 3, Paper Muncher e ir.access il lavoro di adeguamento è reale, e le prime settimane di una release maggiore sono quelle in cui si incontrano i bug che verranno corretti da soli fra due mesi.

Rimanda se il tuo hardware POS o IoT è collegato via IoT Box e non hai ancora verificato cosa succede con Obox.

Rimanda se stai su Odoo 18 e nessuna delle novità della 20 risolve un problema che hai oggi. Una versione in più non produce valore da sola.

Valuta seriamente di muoverti se sei su Odoo 17 o precedenti: con l'uscita della 20, la 17 esce dalla finestra delle versioni supportate da Odoo, e restare su una versione non più manutenuta è una decisione che va presa consapevolmente, non per inerzia. Muoviti anche se l'AI operativa risolve un collo di bottiglia concreto nei tuoi processi, o se sei già su PostgreSQL 16 e Python 3.12 e il tuo parco personalizzazioni è contenuto: in quel caso la finestra di lavoro è corta.

Come affrontiamo una migrazione

Il nostro metodo su questi passaggi è sempre lo stesso, e non è complicato: prima si mappa cosa c'è davvero — moduli custom, report, integrazioni, hardware collegato — poi si migra su una copia, poi si testa con i dati reali del cliente, e solo alla fine si tocca la produzione. La parte che richiede esperienza non è lanciare lo script di upgrade: è sapere in anticipo quali delle tue personalizzazioni si romperanno, e quanto costa rimetterle in piedi.

Se stai valutando il passaggio a Odoo 20 e vuoi capire cosa comporta nel tuo caso specifico, parliamone: un'analisi del parco personalizzazioni esistente dice in poche ore se ha senso muoversi adesso o fra sei mesi.