# Architettura ruoli, moduli e coworking

## Obiettivo

NetGescon non va piu letto come un applicativo monoruolo dedicato solo all amministrazione condominiale.

La direzione corretta e questa:

1. una base dominio unica e coerente
2. moduli attivabili sopra la stessa base dati
3. ruoli e abilitazioni che decidono cosa una persona puo fare
4. stessa persona abilitabile su piu funzioni operative

In pratica: uno spazio unico di coworking operativo, non una somma di mini-app scollegate.

## Base dominio da tenere stabile

La base comune resta:

- anagrafica unica dei nominativi
- stabili, unita immobiliari, relazioni e ruoli
- movimenti, banca, ripartizione spese, piano dei conti
- contabilita in partita doppia
- ticket, allegati, documenti e storico operativo

Questa base non va duplicata per mestiere o per modulo.

## Cosa cambia davvero tra un uso e l altro

Quello che cambia non e il dato di partenza, ma:

- il ruolo
- la procedura disponibile
- il modulo abilitato
- il livello di permesso sul tenant, sullo stabile o sul progetto

Esempi reali della stessa persona:

- supporto informatico
- sviluppo software
- revisione contabile
- collaboratore dell amministratore
- gestione PBX / CTI
- supervisione di ticket e fornitori

## Regola architetturale

NetGescon deve diventare:

- domain-first
- permission-first
- module-first

Non deve diventare:

- menu-first
- pagina-first
- ruolo singolo hard-coded

## Moduli principali gia visibili o in formazione

- Condominio e anagrafica
- Contabilita e banca
- Ripartizioni e tabelle millesimali
- Ticket e Post-it operativi
- CTI / PBX / click-to-call
- Import legacy Gescon
- Revisione contabile
- Storage tenant-aware e archivi
- Distribuzione server e manutenzione nodo

## Effetto pratico sulla UI

La UI deve progressivamente convergere verso:

1. stessa base record
2. azioni visibili solo se abilitate
3. moduli attivabili senza biforcare il prodotto
4. procedure specialistiche innestate sul contesto corretto

Esempio:

- una chiamata entra nel CRM
- produce un Post-it
- il Post-it puo essere assegnato a operatore, collaboratore o fornitore
- se serve diventa ticket
- il ticket impatta documenti, fornitore, stabile, contabilita o revisione

Sempre sullo stesso grafo dati.

## Modello di abilitazione consigliato

Tre livelli distinti:

### 1. Ruolo base

Definisce il perimetro generale:

- amministratore
- collaboratore
- fornitore
- revisore
- tecnico
- sviluppatore / ops

### 2. Capacita operative

Definiscono le azioni concrete:

- vedere contabilità
- modificare ripartizioni
- usare CTI
- lanciare sync staging
- aprire ticket
- assegnare Post-it
- gestire fornitori

### 3. Ambito

Definisce dove valgono:

- tenant / amministratore
- stabile
- progetto
- modulo

## Conseguenza tecnica

Ogni nuova funzione dovrebbe chiedersi prima:

1. su quale base dominio si appoggia
2. quale modulo la ospita
3. quale permission la abilita
4. su quale ambito agisce

Se una funzione non risponde a queste quattro domande, rischia di diventare una pagina isolata e fragile.

## Decisione attuale

La direzione da seguire nelle prossime sessioni e:

1. consolidare i moduli gia emersi invece di moltiplicare pagine parallele
2. portare la gestione operativa sempre piu vicino alle procedure abilitate
3. usare la pagina `Supporto > Modifiche` come ponte fra sviluppo, documentazione e deploy
4. preparare la distribuzione di NetGescon su nodi separati per ambienti di debug e collaudo