Vai al contenuto

Inventario fase 1 - Catalogo moduli tenant

Data audit: 2026-06-29

Scopo

Questa fase fotografa lo stato attuale di moduli, menu, feature, profili, listini e attivazioni tenant. Non introduce codice e non cambia il comportamento dell'applicazione.

L'obiettivo e' preparare la riorganizzazione verso un catalogo moduli unico, dove ogni modulo possa avere:

  • menu e sottomenu propri;
  • attivazione per tenant;
  • stato, validita, scadenza e periodo di grazia;
  • regole operative e limiti quantitativi;
  • feature abilitate o in sola lettura;
  • profili/ruoli collegati;
  • costi derivati da listini e piani commerciali.

Fonti analizzate

  • app/modules/multitenancy/models.py
  • app/modules/multitenancy/entitlements.py
  • app/modules/multitenancy/features.py
  • app/modules/multitenancy/role_profiles.py
  • app/modules/multitenancy/services.py
  • app/modules/multitenancy/views.py
  • app/modules/iam/menu_runtime.py
  • app/modules/iam/menu_service.py
  • app/__init__.py
  • config.py
  • app/modules/service_catalog/models.py
  • app/modules/commerciale/models.py
  • app/modules/commerciale/views.py
  • app/modules/tecnico_files/models.py
  • app/services/osm_sync.py
  • app/services/osm_orders.py
  • app/services/osm_catalog.py
  • documentazione in docs/admin e docs/tecnico

Entita attuali

Area Entita Uso attuale Nota audit
Tenant TenantRegistry Identita tenant, host, database, branding, quota storage, stato attivo Base corretta, ma non e' catalogo moduli
Moduli TenantModuleEntitlement Abilitazione modulo per tenant, stato, date, grace period, note E' il nucleo tecnico piu vicino al catalogo moduli
Feature TenantFeatureFlag Feature granulari con stato, validita e config_json Buona base per sottofunzioni, ma non agganciata formalmente a un modulo catalogato
Profili TenantRoleProfile Definizione profilo, modulo collegato, default readonly Utile per pacchetti di abilitazioni
Profili tenant TenantRoleProfileEntitlement Abilita/disabilita profili per tenant, anche readonly Mancano regole globali di enforcement readonly
Utenti UserRoleProfileAssignment Assegna un profilo a un utente per tenant Attualmente un utente ha un profilo prevalente per tenant
Integrazioni TenantIntegrationProvider, TenantIntegrationConfig Provider/config per modulo e tenant, oggi usato da OSM Da trattare come capability/integration del modulo
Servizi base ServiceCatalog, TenantServiceSubscription Catalogo servizi e attivazioni tenant con prezzo concordato Buona base commerciale generica, ma separata dagli entitlement runtime
Listini RAS/commerciale CommercialeListino, CommercialeListinoServizio, CommercialeListinoFascia, CommercialeListinoRegola Listini, servizi, fasce, regole e prezzi per workflow commerciali/RAS Molto ricco, ma verticale commerciale/RAS
Attivazioni commerciali CommercialeAttivazioneServizio Servizio attivo su cliente/contratto/offerta con rinnovo Non abilita direttamente moduli tenant
Pratiche servizio PraticaServizio Istanza operativa di un servizio su cliente, con contratto, tecnico, documento master E' workflow operativo, non subscription tenant
Limiti tecnici TecnicoFileSpace Quota per utente tecnico, spazio file, stato attivo Primo esempio reale di quantita/limite per modulo

Moduli runtime rilevati

Codice modulo Stato attuale Menu/sottomenu principali Feature collegate Profili collegati Costi/listini/attivazioni Limiti/regole Gap
documentale Gestito da TenantModuleEntitlement; forzato attivo di default via FORCE_MODULES_ENABLED Documentale, categorie, documenti, template, pacchetti, archivio, documenti cliente, import RAS legacy feature.documentale.export_bundle; documentazione cita feature.documentale.versioning_v2, feature.documentale.fast_upload cliente Non ha un listino modulo dedicato; alcuni servizi RAS dipendono dal documentale Readonly parziale in viste documentale Alcuni link document editor non hanno condizione menu; readonly non e' enforcement globale
ras Gestito da entitlement; forzato attivo di default con documentale RAS/Compila, offerta RAS, calcolo RAS, monitor, RAS in lavorazione, export feature.ras.extrabit_zip_export Indiretto: admin_tecnico, profili commerciali, amministratore condominio Molto coperto da CommercialeListino*, CommercialeAttivazioneServizio, contratti AMM, offerte e pratiche Fasce per unita, forfait, quota fissa, regole, pesi equivalenza, rinnovi Il modulo runtime e il prodotto commerciale non sono la stessa entita
commerciale Gestito da entitlement Commerciale, cruscotti, richieste, offerte, contratti, listini, attivazioni, notifiche, rendicontazione feature.commerciale.amm_portale_external_print; feature.contracts.external_print_amm collegata ai contratti gestione, commerciale, operatore_admin, amministratore_condominio, utente_condominio Listini, offerte, contratti, attivazioni, service code commerciali Regole verticali nel commerciale Troppa responsabilita: CRM, vendite, contratti, portale amministratore e listini convivono nello stesso modulo
formazione Gestito da entitlement; tenant specifici con override Formazione, Pianificazione, Didattica, Monitoraggio, WooCommerce, scadenze attestati, reportistica feature.formazione.external_portal, feature.formazione.sso_v1, feature.formazione.certificate_sync_v2 operatore_formazione Sconti formazione, quote, WooCommerce; non risulta aggancio unico a ServiceCatalog Regole sconto e workflow iscrizioni Buona identita modulo, ma pricing e feature sono distribuiti
tickets Gestito da entitlement Ticket, servizi, kanban, conversazioni, import CSV Nessuna feature rilevata come standard Nessun profilo dedicato seed Nessun listino modulo dedicato Nessun limite catalogato Serve decidere se e' modulo vendibile o capability operativa
interventi Gestito da entitlement Interventi, incarichi, rapportini, calendario operativo Nessuna feature rilevata come standard Nessun profilo dedicato seed Nessun listino modulo dedicato Workflow operativo su interventi Dipende/si sovrappone a tecnici e calendar
calendar Gestito da entitlement; se mancante eredita da interventi Calendario globale e sorgenti ticket/interventi/commerciale/formazione Nessuna feature rilevata Nessun profilo dedicato Nessun listino modulo dedicato Sorgenti calendario dipendono da moduli attivi Oggi e' modulo tecnico, forse dovrebbe essere capability trasversale
tecnici Gestito da entitlement Tecnici, cruscotto tecnici, fornitori tecnici, incarichi tecnici, clienti tecnici Nessuna feature rilevata come standard tecnico, admin_tecnico Nessun listino modulo dedicato Relazione con incarichi e file space Confine non netto con interventi e pratiche RAS
tecnico_file_space Gestito da entitlement; default sicuro disabilitato Area file tecnici Nessuna feature rilevata Tecnici/operatori Nessun listino modulo dedicato quota_bytes per tenant/utente, stato attivo Ottimo candidato per limiti quantitativi standard di catalogo
mailops Verificato in menu runtime come modulo separato Archiviazione mail, account mail, dettaglio mail Nessuna feature rilevata Nessun profilo dedicato seed Nessun listino modulo dedicato Nessun limite catalogato Esiste come modulo runtime ma non risulta nei default principali
osm Usato come module_code nelle integrazioni, non come entitlement runtime standard Menu Dorotech: allinea OSM, catalogo OSM, articoli OSM Configurazione provider/config tenant Nessun profilo dedicato seed Nessun listino modulo dedicato Provider, secrets, config JSON Da modellare come integrazione/capability del modulo commerciale o Dorotech
amministratore_condominio Usato come module_code onboarding commerciale Portale/flows amministratore condominio Feature contratti/print esterni amministratore_condominio, utente_condominio Contratti AMM, canoni, rinnovi Onboarding e contratti Oggi e' un sotto-prodotto commerciale, non un modulo runtime coerente
safecondo_compila Presenza di package e viste; non emerso come entitlement standard Compila Safecondo/admin minimale feature.compila.server_first_sync; documentazione cita feature.compila.photo_v2 Non seed dedicato Non dedicato Sync/config Da decidere se submodulo RAS/documentale o modulo prodotto
dvr Package e viste; usa documentale come gate principale Casi DVR, GOE, DUVRI, compilazione DVR Nessuna feature standard rilevata Non seed dedicato Non dedicato Workflow documentale verticale Candidato a modulo verticale separato, ma oggi dipende dal documentale
anagrafiche Fondazionale; non entitlement modulo standard Anagrafiche, persone/clienti, territorio, import/sync feature.anagrafiche.tenant_access Base per molti profili Non dedicato Accesso tenant alle anagrafiche Da trattare come modulo core o servizio infrastrutturale
service_catalog Fondazionale/control-plane Catalogo servizi, attivazioni tenant Non feature Solo global admin/control plane ServiceCatalog, TenantServiceSubscription Status, date, prezzo concordato Va fuso concettualmente con catalogo moduli o mantenuto come catalogo prezzi

Il menu e' costruito in piu punti:

  • registrazione diretta in app/__init__.py con appbuilder.add_view e appbuilder.add_link;
  • condizioni menu_*_enabled_current_tenant;
  • filtro runtime in app/modules/iam/menu_runtime.py;
  • policy menu in app/modules/iam/menu_service.py;
  • policy per label/gruppi/utenti nelle viste IAM.

Il modello e' potente ma fragile: il menu viene deciso da label, categorie, condizioni Python e policy sovrapposte. La visibilita del menu non coincide sempre con autorizzazione server-side sulla rotta.

Control plane oggi disponibile

Schermate gia presenti o registrate:

  • Tenant Registry
  • Provisioning Tenant
  • Tenant Modules
  • Tenant Features
  • Role Profiles
  • Tenant Role Profiles
  • User Role Profiles
  • Policy Menu
  • Policy Menu (Gruppi)
  • Policy Menu (Utenti)
  • Menu Diagnostics
  • Audit Accessi Tenant
  • Catalogo Servizi
  • Attivazioni Tenant
  • Listini
  • Servizi Listino
  • Fasce RAS
  • Regole RAS
  • Attivazioni Servizi

Questo significa che molte parti esistono gia. La mancanza principale non e' la CRUD, ma un modello unico che dica: questo modulo contiene questi menu, queste feature, questi profili, questi limiti e questi piani/listini.

Gap principali

  1. Non esiste un ModuleCatalog canonico. I codici modulo vivono in entitlement, config, menu, feature, onboarding e integrazioni.
  2. TenantModuleEntitlement abilita il modulo runtime, ma non contiene menu, prezzi, limiti, dipendenze o piani.
  3. ServiceCatalog e CommercialeListino* rappresentano prezzi/servizi, ma non sono collegati formalmente agli entitlement modulo.
  4. I menu sono hardcoded e label-based. Questo rende difficile attivare sottomenu per tenant in modo uniforme.
  5. Feature flag e moduli non hanno relazione strutturale. Una feature puo esistere senza sapere a quale modulo appartiene.
  6. Il readonly esiste nei dati, ma non e' un enforcement globale per tutti i moduli.
  7. I limiti quantitativi esistono solo in alcuni verticali, per esempio TecnicoFileSpace.quota_bytes.
  8. Le dipendenze tra moduli non sono dichiarate: ras usa documentale, commerciale, tecnici e contratti; calendar aggrega sorgenti da piu moduli.
  9. Le integrazioni come osm usano module_code, ma non sono nel catalogo moduli runtime.
  10. Le attivazioni commerciali (CommercialeAttivazioneServizio) sono per cliente/contratto/offerta, non per tenant/module subscription.

Raccomandazione di architettura

Creare un catalogo modulare a livelli, senza buttare via le tabelle esistenti:

Nuovo concetto Responsabilita Riusa
ModuleCatalog Anagrafica modulo: codice, nome, descrizione, categoria, stato, owner, tipo modulo Normalizza i codici oggi sparsi
ModuleMenuItem Menu e sottomenu dichiarativi per modulo, con route, label, ordine, icona e requisito permission Sostituisce gradualmente menu hardcoded
ModuleFeature Feature associate a un modulo Riusa TenantFeatureFlag
ModuleProfile Profili suggeriti o richiesti dal modulo Riusa TenantRoleProfile
ModuleDependency Dipendenze obbligatorie/opzionali tra moduli Formalizza ras -> documentale/commerciale
ModulePlan Piano commerciale: base, pro, enterprise, add-on Collega catalogo moduli e listini
ModulePriceList Prezzi e regole per piano/modulo Riusa o collega ServiceCatalog e CommercialeListino*
TenantModuleSubscription Attivazione tenant commerciale/tecnica del modulo Estende o affianca TenantModuleEntitlement
TenantModuleLimit Quantita: utenti, spazio, documenti, pratiche, chiamate, sedi Generalizza esempi come TecnicoFileSpace
TenantModuleRule Regole configurabili per tenant/modulo Usa JSON/config validato, non logica sparsa

Target operativo

Il pannello "Attivazioni Moduli" dovrebbe diventare il punto unico dove un global admin vede:

  • tenant;
  • modulo;
  • piano/listino;
  • stato: trial, active, readonly, suspended, expired, disabled;
  • data attivazione;
  • data scadenza;
  • grace period;
  • costo;
  • limiti;
  • feature incluse;
  • profili abilitati;
  • menu e sottomenu attivi;
  • dipendenze mancanti;
  • note commerciali e operative.

Roadmap proposta

Fase 1A - Inventario tecnico

Stato: completata da questo documento.

Output:

  • lista moduli runtime;
  • lista moduli de-facto;
  • mappa entita;
  • gap principali.

Fase 1B - Validazione business

Da fare prima del codice:

  • decidere nomi commerciali dei moduli;
  • decidere quali moduli sono vendibili e quali sono core/infrastrutturali;
  • decidere quali sotto-moduli diventano add-on;
  • decidere owner funzionale per ogni modulo;
  • decidere service code canonici.

Fase 2 - Disegno modello dati

Produrre specifica tabelle e migrazione:

  • module_catalog;
  • module_menu_item;
  • module_feature;
  • module_profile;
  • module_dependency;
  • module_plan;
  • module_price_list;
  • tenant_module_subscription;
  • tenant_module_limit;
  • tenant_module_rule.

Fase 3 - Adapter su esistente

Prima integrazione senza rivoluzionare tutto:

  • lasciare TenantModuleEntitlement come enforcement runtime;
  • generare/aggiornare entitlement da subscription;
  • collegare feature e profili al catalogo;
  • collegare ServiceCatalog/Listini ai piani;
  • mantenere compatibilita con menu esistenti.

Fase 4 - Menu dichiarativo

Migrare progressivamente i menu:

  • ogni modulo dichiara menu e sottomenu;
  • il runtime filtra per tenant, profilo, feature, stato e readonly;
  • le rotte fanno lo stesso controllo server-side;
  • le label menu diventano conseguenza del catalogo, non fonte di verita.

Fase 5 - Enforcement uniforme

Applicare controllo unico:

  • modulo abilitato;
  • stato valido;
  • data non scaduta o grace attivo;
  • feature abilitata;
  • profilo utente assegnato;
  • readonly rispettato;
  • limite quantitativo rispettato;
  • permesso FAB/route valido.

Decisioni da prendere

  1. documentale e ras devono restare forzati attivi per tutti o diventano attivazioni esplicite?
  2. calendar e anagrafiche sono moduli vendibili o capability core?
  3. dvr, safecondo_compila, mailops, osm diventano moduli separati o add-on di moduli esistenti?
  4. ServiceCatalog diventa catalogo prezzi dei moduli o resta catalogo servizi separato?
  5. CommercialeListino* resta verticale RAS o diventa il motore listini generale?
  6. Il tenant puo avere piu piani per lo stesso modulo o uno solo attivo?
  7. I limiti devono essere per tenant, per utente, per cliente o misti?
  8. Il readonly deve bloccare solo scritture UI o anche API/import/job?

Conclusione fase 1

La modularizzazione proposta e' fattibile e coerente con molte parti gia presenti nel sistema. Il lavoro non parte da zero: entitlement, feature flag, profili, service catalog, listini, attivazioni e policy menu esistono gia.

Il problema attuale e' che sono isole separate. La riorganizzazione deve introdurre un catalogo moduli come fonte canonica, poi collegare progressivamente menu, autorizzazioni, feature, limiti e prezzi a quel catalogo.