3.4 KiB
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:
- una base dominio unica e coerente
- moduli attivabili sopra la stessa base dati
- ruoli e abilitazioni che decidono cosa una persona puo fare
- 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:
- stessa base record
- azioni visibili solo se abilitate
- moduli attivabili senza biforcare il prodotto
- 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:
- su quale base dominio si appoggia
- quale modulo la ospita
- quale permission la abilita
- 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:
- consolidare i moduli gia emersi invece di moltiplicare pagine parallele
- portare la gestione operativa sempre piu vicino alle procedure abilitate
- usare la pagina
Supporto > Modifichecome ponte fra sviluppo, documentazione e deploy - preparare la distribuzione di NetGescon su nodi separati per ambienti di debug e collaudo