Il problema: software verticale per la PA, fatto male
Chi ha lavorato con enti pubblici lo sa: il software gestionale per servizio civile, bandi e commissioni di selezione è quasi sempre una delle due cose — proprietario e costosissimo, oppure open source abbandonato da anni.
Il risultato pratico: fogli Excel che girano via email, PDF compilati a mano, processi di selezione tracciati su carta. Non è nostalgia del passato. È ancora il 2026 e succede così.
Skara nasce per rispondere a questo problema in modo concreto: un gestionale web costruito su Django, pensato per enti che gestiscono progetti di servizio civile e volontariato, dalla pubblicazione del bando fino alla firma dei verbali.
Cosa fa Skara
Il perimetro funzionale è ampio ma coerente. Il sistema copre quattro aree principali:
- Anagrafica: persone, enti, sedi operative, relazioni organizzative tra entità
- Progetti: ciclo di vita completo — da "aperto" ad "archiviato" — con gestione candidature, slot per sede, valutazioni e colloqui
- Commissioni di selezione: costituzione, nomina selettori (con verifica albo SCU), sessioni d'esame, verbali PDF
- Mandati: sistema di autorizzazione e delega — chi può fare cosa, su quale oggetto, per quanto tempo
Le scelte architetturali che contano
Permessi object-level con django-guardian
Il requisito più vincolante era questo: Mario (responsabile dell'ente A) non deve vedere i progetti dell'ente B. Non basta il controllo a livello di modello — serve un sistema di permessi per singola istanza.
Ho usato django-guardian combinato con un modello astratto AuthorizationModel. I permessi vengono assegnati e revocati automaticamente tramite segnali Django, all'attivazione o revoca di un mandato. Le view non toccano mai la logica dei permessi direttamente.
Autenticazione a due fattori obbligatoria
Con django-otp e django-two-factor-auth, il 2FA è integrato nel flusso di login, non opzionale. Trattandosi di un sistema con dati sensibili di candidati e processi selettivi, era un requisito non negoziabile.
Task asincroni con Celery
Alcune operazioni non possono bloccare la request HTTP: geolocalizzazione degli indirizzi (via Geoapify), invio email, generazione di documenti pesanti. Tutto passa per Celery con Redis come broker. I task di geolocalizzazione usano ExponentialBackoff per i retry sulle chiamate API esterne.
Generazione PDF con WeasyPrint
I verbali di commissione, le lettere di convocazione, i report di valutazione sono documenti ufficiali. WeasyPrint genera PDF direttamente dai template Django — nessuna dipendenza da servizi cloud, nessun costo variabile per documento.
REST API con drf-spectacular
L'API v1 è documentata automaticamente tramite schema OpenAPI generato da drf-spectacular. Gli endpoint seguono le convenzioni DRF standard; la logica di business resta nei modelli e nei segnali, non nei serializer.
La struttura del codice
Il progetto è diviso in otto app Django, ognuna con una responsabilità chiara:
- base — modelli astratti (BasicModel, TimestampModel, GeoModel), permessi, task, utilities condivise
- authentication — utente custom email-based, 2FA, notifiche account
- anagrafica — Person, Company, Headquarter, Mandate
- projects — Project, SelectionCommittee, Application, Interview, Evaluation
- announcements — configurazione bandi e ciclo di vita
- api — endpoint REST v1
- cms — contenuti statici
- login_as — utility per impersonare utenti in fase di supporto
Deploy e configurazione
Il deploy è completamente containerizzato con Docker Compose. I parametri sensibili — chiavi, credenziali database, configurazione email, API key Geoapify — sono in file .cnf separati, mai nel repository. In produzione: Gunicorn come application server, Nginx come reverse proxy, Redis per broker e cache, PostgreSQL come database principale.
Lo sviluppo gira su SQLite per semplicità. Il passaggio a PostgreSQL in staging o produzione non richiede modifiche al codice.
Quello che non è
Skara non è un ERP. Non gestisce contabilità, non ha un modulo HR completo, non ambisce a coprire ogni processo di un ente pubblico. Fa bene una cosa specifica: il ciclo di vita dei progetti di servizio civile e la selezione dei candidati.
Questa scelta di perimetro è deliberata. Un sistema che prova a fare tutto tende a non fare niente bene. Meglio un'applicazione verticale, solida, con un dominio ben definito e API che permettono l'integrazione con altri sistemi quando necessario.
Costruire software per la pubblica amministrazione italiana richiede più pazienza che tecnologia. I vincoli normativi, i processi di approvazione, la necessità di audit trail completi — tutto questo si traduce in scelte architetturali precise. Skara è il risultato di quelle scelte, e continua a evolversi con i requisiti reali degli enti che lo usano.