6.2 KiB
Report Gap Analysis – PEChub PEC Manager SaaS Analisi condotta il 25/03/2026 sul codice sorgente (backend, worker, frontend).
COSA E' IMPLEMENTATO E FUNZIONANTE Infrastruttura e autenticazione
Stack Docker completo (PostgreSQL, Redis, MinIO, Nginx, backend, worker, frontend) Autenticazione JWT con refresh token silenzioso 2FA TOTP (setup + verifica) Multi-tenancy row-level con RLS PostgreSQL Cifratura credenziali IMAP/SMTP (AES-256-GCM in security.py) Rate limiting su endpoint auth WebSocket real-time per nuovi messaggi CRUD completo: caselle, utenti, permessi, Virtual Box, notifiche, etichette IMAP Sync Engine
Pool asincrono con N coroutine IMAP, IDLE + polling fallback Backoff esponenziale su disconnessione Download EML grezzo su MinIO Aggiornamento stato casella (error, sync_error_count) Parser PEC
Classificazione tipo messaggio da header X-Ricevuta/X-TipoRicevuta Parsing MIME completo, estrazione allegati EML-in-EML (ricevute annidate) State machine outbound: sent → accepted → delivered / anomaly Invio SMTP
API POST /send con validazione e creazione send_job Job send_pec con retry esponenziale (5 tentativi) receipt_watcher: attesa ricevuta accettazione con alert anomalia a 24h Upload raw EML inviato su MinIO Frontend
Inbox multi-casella con filtri, selezione multipla, azioni bulk Posta inviata, Preferiti, Archiviati, Cestino Dettaglio messaggio: corpo HTML/testo, allegati, ReceiptTree, download ZIP Composizione PEC con RichTextEditor, To/Cc multipli, allegati Gestione caselle, utenti, permessi, Virtual Box, notifiche, impostazioni Pagina Multi-tenant (Super Admin) Tag/etichette con colori su messaggi Virtual Box con regole e assegnazioni utenti COSA MANCA – PRIORITA' ALTA
- Dispatch automatico notifiche (Sistema di notifiche incompleto al 60%)
Il CRUD canali/regole/log e' implementato, ma manca tutto il lato dispatch Non esiste worker/app/jobs/dispatch_notification.py NotificationService non ha il metodo evaluate_rules(event_type, message) che valuta le regole e accoda i job L'IMAP sync (sync.py) non chiama nulla al salvataggio di un nuovo messaggio Il test canale webhook e email e' uno stub che restituisce sempre successo (solo Telegram ha invio reale) La cifratura in notification_service.py usa base64 grezzo, non AES-256-GCM: i segreti (bot_token, webhook_secret, smtp_password) sono leggibili in chiaro nel DB Canale WhatsApp: nessuna implementazione reale (stub completo) Canale Email SMTP: nessuna implementazione reale (stub completo) Risultato pratico: le notifiche sono configurabili ma non vengono mai inviate automaticamente
- Archiviazione Sostitutiva (Fase 6 – ~15% implementata)
worker/app/archival/conservatore_client.py esiste (mock + produzione) ma non e' mai chiamato da nessun job reale Mancano completamente: worker/app/archival/sip_builder.py (generazione pacchetto SIP UNI SInCRO) worker/app/archival/rdv_processor.py (parsing RdV XML) worker/app/jobs/archive_batch.py (job selezione messaggi + upload SIP) backend/app/api/v1/archival.py (endpoint GET /archival/batches, POST /archival/dip) frontend/src/pages/Archival/ (pagina log versamenti, download RdV, richiesta DIP) Il modello archival.py esiste ma la tabella archival_batches non e' nella migrazione corrente La configurazione conservatore nelle impostazioni tenant e' pronta, ma il "pulsante" che avvia il versamento non esiste
- Worker – job mancanti
dispatch_notification.py – notifiche automatiche archive_batch.py – versamenti verso conservatore generate_report.py – export PDF/CSV index_message.py – indicizzazione FTS allegati via Tika 7. Sicurezza – punti critici
La cifratura dei segreti notifiche usa base64.b64encode() senza encryption reale: chiunque abbia accesso al DB puo' leggere bot_token Telegram, webhook secret, SMTP password in chiaro Il CI/CD GitHub Actions e' disabilitato (ci.yml.bak): non c'e' lint automatico, test o build su PR Non c'e' docker-compose.prod.yml (override produzione con configurazioni rafforzate) Docs /docs, /redoc sono disabilitate in produzione ma non c'e' un meccanismo di secret scan
- Gestione quote casella
L'evento mailbox.quota_warning e' definito negli enum delle notifiche ma non e' mai generato dal worker (nessuna stima della quota IMAP) COSA MANCA – PRIORITA' BASSA (Hardening / Go-Live) 11. Monitoring e osservabilita'
Non c'e' infra/prometheus/ ne' infra/grafana/ (previsti in ARCHITECTURE.md ma non creati) Non c'e' log aggregation (Loki/ELK) Non ci sono metriche esposte dal backend (es. /metrics endpoint Prometheus) 12. Backup automatico
Non c'e' script o cronjob per pg_dump automatico verso MinIO 13. Test coverage
I test di integrazione esistenti coprono auth, users, send API Non ci sono test per: messages API, permissions API, virtual_boxes, notifications, archival Non c'e' copertura frontend (nessun test Vitest/Playwright presente) 14. GDPR
Non c'e' endpoint DELETE /tenants/{id} per cancellazione completa dati tenant con audit trail RIEPILOGO STATO PER FASE Fase Descrizione Stato 1 Fondamenta + Auth + Multi-tenancy Completa 1-A Permessi granulari per casella Completa 2 IMAP Sync Engine Completa 3 Parser PEC e Tracking Ricevute Completa 4 Invio SMTP con retry Completa 5 Frontend base (inbox, compose, admin) Completa 5-A Virtual Box Completa 5-B Ricerca avanzata full-text Non iniziata 5-C Notifiche multi-canale Struttura pronta, dispatch mancante 6 Archiviazione sostitutiva ~15% (client mock presente, tutto il resto mancante) 7 Dashboard e Reportistica Non iniziata 8 Hardening, test, go-live Parziale (sicurezza base presente, monitoring/backup/CI mancanti) PRIORITA' DI INTERVENTO CONSIGLIATA Notifiche dispatch – e' la funzionalita' piu' vicina al completamento: la struttura dati e' pronta, manca solo il wiring tra IMAP sync, il servizio di valutazione regole e il job worker. Ha alto impatto operativo. Ricerca avanzata – blocca l'usabilita' su volumi di posta significativi. La ricerca ILIKE attuale scala male. Archiviazione sostitutiva – obbligatoria per la compliance normativa dei clienti PA/professionisti. Fix sicurezza cifratura notifiche – critico: i segreti (bot token, webhook secret) sono attualmente non cifrati nel DB. Audit log – necessario per compliance e per l'utilizzo enterprise. Dashboard/Report – utile commercialmente ma non bloccante per l'operativita'.