146 lines
3.4 KiB
Markdown
146 lines
3.4 KiB
Markdown
# 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
|