Moduli Abilitati

Per decidere se un modulo (es. Magazzino, Sistema TS, Corrispettivi) è visibile a un utente di un workspace, NOX applica tre filtri indipendenti in intersezione. Tutti e tre devono dire «sì» per mostrare il modulo.

Prima della certificazione v 2.2 esistevano solo due configurazioni scollegate:

• Profilo attività: stringa in Parametri, usata per terminologia ma non filtrava i menu
• menuConfig utente: priorità assoluta, permetteva conflitti silenziosi (un dentista poteva attivarsi «magazzino» senza che nessuno lo notasse)

Mancava una separazione netta tra:

I 7 pacchetti commerciali disponibili:

Caratteristiche

• Attivazione tracciata: attivato_il, attivato_da
• Disattivazione tracciata: disattivato_il, disattivato_da (non elimina il record, marca attivo=false)
• BASE sempre ON: il toggle è disabilitato, il pacchetto è tecnicamente impossibile da disattivare
• Effetto immediato: dopo il salvataggio, alla prima chiamata API l'utente non vedrà più i moduli del pacchetto disattivato

Il profilo attività (Parametri → Dati Aziendali) definisce quali moduli sono rilevanti per quel tipo di impresa, nell'intersezione con i pacchetti attivi.

12 profili preconfigurati:

UI nei Parametri

Nella pagina Dati Aziendali, accanto alla label "Profilo Attività" c'è un pulsante «Moduli» che apre una modal con le due colonne:

• Auto-attivati (verde): moduli rilevanti per il profilo corrente
• Nascosti per questo profilo (grigio): moduli disponibili ma non pertinenti (tooltip con motivazione)

Ogni utente ha un suo menuConfig che contiene le chiavi modulo con valore true/false.

Comportamento in Modifica Utente → Moduli

• I moduli non permessi dai livelli 1+2 appaiono disabilitati, barrati, con badge BLOCCATO e tooltip che spiega il motivo (es. «Pacchetto MAGAZZINO non attivo» oppure «Non rilevante per il profilo STUDIO_MEDICO»)
• I moduli permessi da 1+2 sono toggolabili liberamente dall'admin del cliente
• Anche se l'admin del cliente forza un toggle, il backend rifiuterà la chiamata API del modulo bloccato (HTTP 403)

La formula che applica il sistema:

Se uno solo dei tre filtri ritorna false, il modulo non è visibile.

1. TU come SUPERADMIN: apri /admin/pacchetti, seleziona il workspace del nuovo cliente, spunta i pacchetti acquistati. Salva. (BASE già attivo.)
2. Admin del cliente: apre Parametri → Dati Aziendali, seleziona il suo Profilo Attività. Clicca il pulsante "Moduli" per vedere l'anteprima dei moduli attivati/nascosti. Salva parametri.
3. Admin del cliente: va in Utenti → Modifica Utente, configura i permessi specifici per ciascun dipendente (es. la commessa vede solo Corrispettivi, il contabile vede solo Registri IVA + Piano Conti).
4. Gli utenti operano: ogni volta che aprono un menu o chiamano un'API, i tre filtri vengono applicati automaticamente.

Sidebar / Topbar

Ogni voce di menu viene filtrata da AuthService.isMenuEnabled(key) che applica in ordine livello 1 → 2 → 3. Il menu della voce bloccata non compare proprio: l'utente non vede neanche che esiste.

Chiamate API

Il middleware backend richiedeModulo(moduloKey) sui route sensibili:

• Passa il controllo se tutti e 3 i livelli approvano
• Ritorna HTTP 403 Forbidden con JSON: {"error": "Modulo 'X' non accessibile: <motivo>", "dettaglio": {...}}
• SUPERADMIN bypassa i livelli 2 e 3 (ma non 1)

Endpoint /api/me/moduli-attivi

Restituisce l'elenco dei moduli effettivamente visibili all'utente corrente, con dettaglio di ciascun check (pacchettoOk, profiloOk, utenteOk) per debug.

Dalla topbar, il pulsante dorato «Moduli Abilitati» (con icona inventory) è visibile solo per SUPERADMIN.

Layout della pagina

1. Selettore workspace: dropdown con i workspace disponibili
2. Griglia di card pacchetti: una card per ciascun pacchetto (7 totali), con toggle di attivazione e lista dei moduli inclusi
3. Footer sticky: appare solo se ci sono modifiche non salvate, con pulsanti Salva e Annulla

Aspetto delle card

• Card attiva: bordo verde, opacità piena
• Card inattiva: bordo grigio, opacità 55%
• Card BASE: toggle disabilitato con etichetta "sempre attivo"

1. Modifica i toggle dei pacchetti
2. Il footer sticky mostra il numero di modifiche pendenti
3. Clicca Salva modifiche: PUT /api/pacchetti/workspace/:wsId
4. Il backend aggiorna pacchetti_workspace riga per riga: se il pacchetto cambia da attivo a inattivo (o viceversa), registra disattivato_il/da o attivato_il/da
5. Messaggio di conferma "Pacchetti aggiornati". La lista viene ricaricata.

Scenario: il cliente cambia contratto e rimuove il pacchetto MAGAZZINO.

1. Avvisa il cliente: i suoi utenti perderanno l'accesso ai moduli magazzino al prossimo refresh della pagina
2. Verifica transizioni aperte: assicurati che non ci siano movimenti di magazzino in bozza o inventari in corso che l'utente dovrà comunque completare
3. Disattiva il toggle MAGAZZINO in /admin/pacchetti del workspace
4. Salva
5. I dati storici non vengono cancellati: restano consultabili solo da SUPERADMIN, che bypassa il filtro 2 ma non il 1 (quindi vede solo moduli del pacchetto BASE+altri attivi)

Tabelle nel DB master gestione

Endpoint API

Il ruolo SUPERADMIN ha comportamento speciale nella gerarchia:

Nel catalogo moduli, alcune voci sono marcate come indispensabile: true e non sarebbero mai disattivabili. In pratica questa rigidità crea problemi: un naturopata forfettario non ha bisogno dei Registri IVA, un professionista senza cassa non vuole vedere la voce Rivalsa INPS, un consulente non spedisce nulla quindi non serve la voce Spedizioni. Dalla versione 2.2, il backend declassa automaticamente certi moduli in base al contesto letto dai Parametri aziendali (tab Fatturazione-Cassa).

I 3 tipi di moduli

Le 4 regole di declassamento fiscale

L'endpoint GET /api/pacchetti/workspace/:wsId/moduli-config legge 4 campi dai Parametri del workspace e applica le regole sotto:

Esempi pratici (stessa azienda, 3 regimi diversi)

Legenda: 🔒 obbligatorio = toggle bloccato, l'utente non può disattivarlo. ✅ sbloccato = toggle libero, l'admin decide. libero = lo era già (nel DB indispensabile: false).

Response API con nuovi campi

GET /api/pacchetti/workspace/:wsId/moduli-config

{
  "profilo":     "STUDIO_NATUROPATICO",
  "regime":      "RF19",
  "forfettario": true,
  "contesto": {
    "regime":         "RF19",
    "cassaPrevId":    null,
    "tipoAnagrafica": "PERSONA_FISICA",
    "tipoAttivita":   "STUDIO_NATUROPATICO"
  },
  "pacchetti":   ["BASE", "FATTURAZIONE", "CONTABILITA", "MAGAZZINO"],
  "moduli": [
    {
      "moduloKey":      "registro-iva",
      "indispensabile": false,
      "disabilitato":   false,
      "declassato":     true,
      "motiviDeclass":  ["FORFETTARIO"],
      "motivoDisab":    null,
      ...
    },
    {
      "moduloKey":      "listini",
      "indispensabile": false,
      "disabilitato":   false,
      "motiviDeclass":  ["OPERATIVO"],
      ...
    }
  ]
}

Codice — dove modificare le liste

Per aggiungere/togliere moduli dalle 4 categorie, editare backend/services/modulo-access.service.js:

• MODULI_IVA_DECLASSATI — moduli liberati dal regime forfettario
• MODULI_CASSA_PREV — moduli liberati se nessuna cassa
• MODULI_SOLO_PROFESSIONISTA — moduli liberati per società
• MODULI_SANITARI — moduli liberati per attività non sanitarie
• MODULI_OPERATIVI_SBLOCCABILI — moduli sempre liberi a prescindere dal contesto