Vai al contenuto

Besant Tenant-Neutralization TODO

Scopo

Questa nota tecnica serve a identificare i punti concreti da sbloccare per rendere tenant_besant davvero indipendente dalle policy storiche nate per Safecondo.

Non e una roadmap generica.
E una lista operativa file -> problema -> azione consigliata.

Obiettivo

Arrivare a questo stato:

  • tenant_besant governa moduli, menu e listini senza dipendere da alias safecondo
  • Safecondo continua a funzionare
  • il codice non assume piu che alcune capability RAS/documentale/listino esistano solo nel mondo Safecondo

1. Menu runtime documentale/RAS

File

Problema

Ci sono forzature esplicite legate a safecondo:

  • module_enabled_current_tenant(..., safecondo_force=True)
  • is_safecondo_runtime()
  • forcing menu labels quando tenant_key in {"safecondo", "tenant_safecondo"}

Questo significa che documentale/RAS non sono governati in modo puramente tenant-driven.

Azione consigliata

Sostituire la logica:

  • da: eccezione Safecondo
  • a: entitlement/modulo attivo per tenant

Regola target:

  • Besant vede documentale/RAS se il modulo e attivo
  • Safecondo continua a vederli perche il modulo e attivo, non perche e Safecondo

Priorita

Alta

2. Policy listini limitata a Safecondo

File

Problema

La funzione:

  • _safecondo_listino_enabled_tenant()

e le relative condizioni menu fanno passare solo tenant safecondo/tenant_extra/safeops.

Questa e oggi la parte meno portabile.

Azione consigliata

Rinominare concettualmente la policy:

  • da: safecondo_listino_enabled
  • a: tenant_listino_enabled

e pilotarla con:

  • modulo commerciale attivo
  • flag tenant o setting dedicato
  • eventuale capability can_manage_listini

Nel frattempo, per evitare accoppiamenti fra Safecondo e Besant:

  • clonare il pacchetto listini da tenant_extra a tenant_besant
  • lasciare i listini separati, in modo che variazioni future non si propaghino tra tenant
  • agganciare i listini clonati alla rete commerciale Besant solo dopo verifica dei record target

Comando disponibile:

FLASK_APP=app flask commerciale_clone_listini \
  --source-tenant tenant_extra \
  --target-tenant tenant_besant \
  --dry-run

Il comando clona:

  • commerciale_listino
  • commerciale_listino_servizio
  • commerciale_listino_fascia
  • commerciale_listino_regola

e, se richiesto, crea/aggiorna anche i link commerciale_rete_listino con:

  • --target-rete-commerciale-id
  • --default-listino-name

Regola target

Besant deve poter governare:

  • listini
  • servizi listino
  • fasce RAS
  • regole RAS
  • preset equivalenze

senza passare da alias safecondo.

Priorita

Alta

3. Alias tenant storici

File

Problema

Safecondo usa ancora alias storici:

  • tenant_extra
  • safecondo
  • safeops

Questo rende comprensibili i workaround storici, ma complica la neutralita del codice.

Azione consigliata

Non migrare subito Safecondo.
Prima isolare l'uso degli alias in un punto solo:

  • resolver centralizzato tenant runtime
  • mapping alias -> tenant canonico

Regola target

Il resto del codice applicativo deve lavorare su tenant canonico, non su alias sparsi.

Priorita

Media-Alta

4. Documentazione amministrativa listini

File

Problema

La documentazione oggi dice esplicitamente che la governance listini e visibile solo sul tenant safecondo.

Azione consigliata

Aggiornare il documento dopo la neutralizzazione:

  • distinguere policy storica e policy target
  • documentare Besant come tenant pienamente governabile

Priorita

Media

5. Checklist go-live Besant vs codice reale

File

Problema

La checklist Besant e buona, ma oggi il codice non e ancora del tutto coerente con l'idea che Besant possa governare gli stessi menu/listini in modo autonomo.

Azione consigliata

Quando i punti 1-2 saranno chiusi:

  • riallineare la checklist Besant
  • aggiungere una sezione breve Prerequisiti piattaforma
  • distinguere:
  • prerequisiti dati
  • prerequisiti menu/policy

Priorita

Media

6. Test da fare dopo neutralizzazione

Test minimi

  1. tenant_besant con moduli attivi:
  2. vede documentale
  3. vede RAS

  4. vede listini se autorizzato

  5. tenant_extra / Safecondo:

  6. continua a funzionare come prima

  7. non perde menu o capability

  8. utente admin_tenant Besant:

  9. accede a listini/fasce/regole
  10. salva preset

  11. apre flusso RAS end-to-end

  12. utente non autorizzato:

  13. non vede menu amministrativi listino

Ordine consigliato

  1. neutralizzare menu documentale/RAS
  2. neutralizzare policy listini
  3. centralizzare alias tenant
  4. aggiornare documentazione
  5. fare collaudo Besant completo

Conclusione

Il punto chiave non e riscrivere il processo.
Il punto chiave e togliere dal codice applicativo le eccezioni Safecondo nei punti che oggi bloccano Besant come tenant di prima classe.