Utenti e permessi

01Creare utenti e assegnare ruoli

La gestione di utenti, ruoli e permessi è riservata agli amministratori. Il primo admin nasce dallo script di bootstrap in fase di installazione; da lì crei tutti gli altri utenti dalla sezione admin.

• Nuovo utente: imposti username, email e una password iniziale (c'è un pulsante Genera che ne crea una robusta, con indicatore di forza e copia). Il flag "deve cambiare la password al primo accesso" è attivo di default: l'utente sceglierà una password propria al primo login.
• Ruolo: a ogni utente assegni un ruolo (uno solo): è il ruolo, con la sua posizione nella gerarchia, a determinare tutti i permessi.
• Ciclo di vita: puoi disattivare un utente (senza cancellarlo) o resettargli la password. L'eliminazione definitiva riassegna a te i record che possedeva.

Un permesso è sempre la tripla modulo · azione · scope: ad esempio trattative · update · team significa "può modificare le trattative del proprio team". Le azioni sono create, read, update, delete, export, admin, più il permesso speciale manage sui workflow (consente di gestire le automazioni senza essere amministratori: vedi Workflow). In assenza di una regola, l'accesso è negato per default.

02Ruoli gerarchici

I ruoli formano una gerarchia: un ruolo può avere un ruolo padre. La regola fondamentale è che un figlio non può concedere più del padre. Un ruolo "Venditore junior" figlio di "Venditore" non potrà mai ottenere permessi che il "Venditore" non ha: la gerarchia funziona come un tetto che il figlio non può sfondare.

• I ruoli di sistema (incluso admin, che è in sola lettura) non sono eliminabili.
• I ruoli custom li crei tu, definendo padre e permessi, per riflettere l'organizzazione reale.
• Il dialog dei permessi rende visibile il tetto: i permessi che il padre non ha appaiono con un lucchetto e non sono concedibili; nulla si applica finché non salvi, e restringendo un ruolo con discendenti il sistema mostra quanti ruoli e utenti erediteranno la stretta.

La stessa gerarchia governa anche a chi puoi intestare i record: proprietario e assegnatario si possono impostare solo su sé stessi o su un proprio sottoposto (un utente con un ruolo discendente del tuo). Un manager riassegna quindi i record del suo team, ma non può "regalarli" a colleghi di altri rami; solo l'amministratore assegna a chiunque. È un vincolo indipendente dalla visibilità: vedere un record non basta per poterlo riassegnare.

03Visibilità: own, team, all

Lo scope risponde alla domanda "su quali record vale questo permesso?". Ha tre livelli, applicati direttamente nelle query al database:

• own: solo i record di cui l'utente è proprietario o assegnatario. Esempio: un venditore vede e modifica solo le proprie trattative.
• team: anche i record dei colleghi dello stesso team. Esempio: un team leader vede tutte le trattative del suo team, non solo le sue.
• all: tutti i record del modulo, senza filtri. Esempio: un direttore commerciale o un admin.

Lo scope si combina con l'azione: si può concedere read · all ma update · own, cioè "puoi vedere tutte le trattative ma modificare solo le tue". È così che si costruisce una visibilità realistica senza aprire tutto a tutti.

04Permessi per campo

Il controllo non si ferma al modulo: puoi decidere l'accesso campo per campo, per ruolo. Ogni campo ha uno di tre livelli (anch'essi cappati al livello del ruolo padre):

• Nascosto: il campo non appare nell'interfaccia, ed è filtrato anche dall'API e dagli export. Chi non può leggerlo non ne trova traccia.
• Sola lettura: il campo si vede ma non si modifica.
• Lettura e scrittura: accesso pieno.

Il caso tipico è l'importo di una trattativa: lo rendi visibile e modificabile ai commerciali, in sola lettura ai manager e nascosto a chi non deve conoscere le cifre. Un tentativo di scrivere un campo non consentito viene respinto dall'API con l'elenco dei campi negati.

05Team

I team sono i gruppi che danno significato allo scope team. Crei un team, ci assegni degli utenti, e da quel momento un permesso con scope team concede a ciascun membro la visibilità sui record dei colleghi dello stesso team.

06MFA e audit log

Oltre ai permessi, due strumenti proteggono l'istanza e ti dicono cosa è successo:

• MFA (TOTP): ogni utente può attivare l'autenticazione a due fattori con un'app come Google Authenticator o Authy: enroll, scansione del QR, conferma del codice. Il CRM genera anche codici di recupero cifrati per non restare chiusi fuori.
• Audit log: un registro append-only (immutabile) traccia chi ha fatto cosa sui record: attore, evento, modulo, azione, esito (successo/fallito), IP. È filtrabile per attore, tipo di evento, modulo e data. Non copre l'amministrazione degli accessi: creazione e modifica di utenti, ruoli e permessi, e reset password da amministratore, oggi non lasciano una riga nel registro. Fanno eccezione i team e il reset dell'MFA, che invece la lasciano.
• Sessioni: ogni utente vede le proprie sessioni attive (IP, user agent) e può revocarne una o tutte le altre in blocco.

Per gestire utenti, ruoli e team via API, vedi API · Utenti e team.