Moduli e Flussi¶
Moduli principali¶
anagrafiche: clienti, tipologie, ATECO, geo alias, dipendenti, contesto.documentale: categorie, upload documenti, versioni, checklist.tickets: ticket intervento/bugfix/variazione, chat ticket.commerciale: reti di gestione, reti commerciali, richieste servizio, trattative, offerte, rinnovi, perimetro visibilita.multitenancy: tenant registry, provisioning, upgrade tenant.storage: integrazione MinIO/S3, quote.access_control: template permessi, gruppi utente, policy.service_catalog: catalogo servizi e sottoscrizioni tenant.formazione: corsi, date/orari, iscrizioni, presenze, attestati, survey qualità .
Flussi core¶
1) Cliente¶
- creazione cliente su tenant;
- eventuale allineamento globale;
- gestione dati contesto dinamici per tipologia;
- documenti, ticket, dipendenti collegati.
2) Documento cliente¶
- scelta cliente e categoria;
- upload master + allegati;
- aggiornamento/versioning;
- vista checklist per stato copertura documentale.
3) Ticket¶
- apertura ticket (cliente, tipo, priorita);
- assegnazione e stato lavorazione;
- chat operativa;
- chiusura e storico.
4) Dipendenti¶
- anagrafica dipendente;
- associazione cliente-dipendente;
- visibilita in cliente show (related).
5) Mappa clienti/interventi¶
- marker clienti geolocalizzati (lat/lon comune);
- overlay stato ticket/interventi aperti;
- popup con link rapido a cliente e ticket.
6) Formazione (date -> ruoli)¶
- operatore crea corso e imposta
Date e Orari; - operatore iscrive discenti;
- docente gestisce presenze (mattina/pomeriggio) e completamento;
- operatore genera/carica attestati e scadenze;
- invio survey e consolidamento KPI qualità .
Evoluzione architetturale consigliata:
7) Commerciale e Perimetro Servizi¶
Oggetti principali¶
CommercialeReteGestioneCommercialeReteCommercialeCommercialeClienteServizioLinkCommercialeRichiestaServizioCommercialeTrattativaCommercialeOffertaCommercialeTecnicoIncarico
Regola di modello¶
Il sistema non usa solo gerarchia tenant. Usa:
- anagrafiche del tenant;
- tipologie cliente;
- collegamenti per singolo servizio;
- incarichi tecnici;
- consensi separati.
Questo permette:
- un cliente collegato a piu reti commerciali per servizi diversi;
- una rete di gestione che vede solo i dati consentiti;
- un tecnico limitato ai clienti con incarico attivo.
Flussi applicativi¶
ras_quote- richiesta -> trattativa -> offerta RAS -> ticket/documento/servizio attivo
quote_simple- richiesta -> trattativa -> offerta semplice
ticket_only- richiesta -> ticket diretto
document_request- richiesta -> documento / gestione documentale
generic_request- richiesta generica instradata internamente
Enforcement visibilita¶
Il perimetro viene calcolato nel modulo commerciale e poi applicato anche a:
Commerciale -> Richieste ServizioCommerciale -> TrattativeCommerciale -> OfferteServizi -> TicketDocumentale -> Documenti
L'enforcement si attiva per utenti collegati a:
CommercialeAgente.user_idCommercialeReteGestione.user_idCommercialeTecnicoIncarico.user_id
Se un utente non e collegato a nessun profilo scoped:
- il comportamento resta non restrittivo
- utile per utenti amministrativi interni.
Diagnostica¶
Per il debug operativo:
Commerciale -> Matrice PermessiCommerciale -> Diagnostica Visibilita'
Queste due viste servono a verificare:
- permessi FAB minimi per ruolo;
- clienti e record visibili;
- coerenza del perimetro prima di stringere ulteriormente i permessi.