Audit stampe SafeOps - 2026-07-25

Obiettivo

Allineare progressivamente le stampe SafeOps alla nuova logica trasversale:

• tenant-aware;
• branding corretto per Safecondo/Besant e futuri tenant;
• template versionati dove serve;
• output persistito con DocumentoVersion;
• fallback tracciato;
• niente invii email impliciti durante la generazione.

Stato per famiglia

Famiglia stampa	Entry point	Motore	Persistenza/versioning	Branding tenant	Stato
RAS finale	run_ras_final_print_job	verticale ReportLab v2 oppure snapshot cristallizzato	si, persist_ras_outputs	si, Safecondo/Besant	allineato
RAS v2 / nuova stampa	run_ras_reportlab_v2_job	ReportLab v2	si, persist_ras_outputs + libretto	parziale tramite payload RAS	quasi allineato
Bozza RAS	run_ras_draft_print_job	DOCX template + conversione PDF + schede verticali con fallback legacy	si, PDF + DOCX + versioni	usa _build_ras_print_payload_for_doc	primo allineamento completato
DOCX RAS	run_ras_draft_docx_job, run_ras_libretto_docx_job	DOCX template registry/mapping	si, persist_ras_docx_output	dipende dal template/payload	tracciamento template completato
NC RAS	print_nc_report	ReportLab dedicato	si, documento + versione	si, via branding RAS	primo allineamento completato
Assemblea RAS	_run_ras_assemblea_pdf_job	ReportLab dedicato	si, documento + versione	si, header/footer tenant-aware	primo allineamento completato
IDS-A PDF demo	run_ras_ids_a_pdf_demo_job	HTML + WeasyPrint	solo StoredFile, non DocumentoVersion	specifico IDS-A	fuori standard
Offerte/preventivi RAS	_build_ras_offer_order_pdf_bytes	document-engine esterno con fallback DOCX locale	si per preventivi/moduli/firmati ufficiali	Besant parziale	primo versioning completato
Formazione preventivo	_write_training_quote_pdf_tmp	ReportLab	temporaneo + flusso offerta	tenant branding dedicato formazione	separato, ok per ora
Formazione attestati/registri	app/modules/formazione/services.py	ReportLab	si in alcune funzioni	tenant branding formazione	audit separato

Evidenze principali

RAS finale

File: app/services/print_engine/base.py

Il finale e' ora il riferimento migliore:

• usa _render_ras_final_outputs;
• supporta renderer verticale;
• fallback legacy/DOCX tracciato;
• Besant ha default branding dedicato;
• Safecondo e Besant hanno registry ras/ras_master/v35.

Nota: se il RAS e' gia cristallizzato, il finale riusa lo snapshot congelato. Ora viene tracciato come render_engine=crystallized_snapshot.

Bozza RAS / DOCX RAS

File: app/services/print_engine/base.py

La bozza usa ora questo flusso:

• DOCX template da _resolve_ras_master_template_path;
• conversione DOCX -> PDF;
• schede verticali quando il tenant e' abilitato al verticale;
• fallback automatico a render_ras_section_pdfs legacy se il verticale fallisce;
• salvataggio versionato.
• metadata render_engine, render_engine_version, template_version_id e motore schede salvati sul documento.

Rischio residuo: il master bozza resta DOCX modificabile e quindi puo' differire dal PDF finale verticale, ma le schede sono allineate al renderer finale.

NC RAS

File: app/modules/documentale/views.py File: app/services/print_engine/renderers/ras_non_conformita.py

La stampa NC e':

• generata inline via send_file, mantenendo l'esperienza esistente;
• salvata anche come Documento;
• versionata con DocumentoVersion;
• collegata a categoria RAS e RAS Non conformita;
• header/footer tenant-aware con dati branding;
• nessuna TemplateRegistry.

Rischio residuo: non usa ancora una TemplateRegistry, perche' il layout e' ReportLab puro.

Assemblea RAS

File: app/modules/documentale/views.py File: app/services/print_engine/renderers/ras_assemblea.py

La stampa assemblea e':

• persistita come documento;
• versionata con _create_document_version;
• ha renderer ReportLab dedicato;
• usa branding tenant/logo in header/footer;
• registra print_engine_version;
• non usa registry template.

Rischio residuo: non usa ancora una TemplateRegistry, perche' il layout e' ReportLab puro.

IDS-A PDF demo

File: app/modules/commerciale/views.py

Il PDF IDS-A:

• usa template HTML + WeasyPrint;
• salva solo in StoredFile;
• sostituisce il precedente disattivandolo;
• non crea DocumentoVersion;
• e' volutamente specifico IDS.

Rischio: non va mischiato subito con Safecondo/Besant; serve decidere se resta demo IDS o diventa stampa ufficiale.

Offerte/preventivi RAS

File: app/modules/commerciale/views.py

Il flusso ordine/preventivo RAS:

• prova document-engine esterno;
• per Safecondo/Besant usa DOCX locale con logo tenant, evitando il logo Extra del document-engine;
• se il document-engine viene usato e fallisce, usa fallback locale DOCX e lo traccia nei metadata;
• Besant ha branding parziale gia introdotto;
• preventivi, moduli ordine e caricamenti firmati ufficiali creano DocumentoVersion;
• aperture preview offerta restano inline quando non si consolida un documento.

Rischio residuo: duplicazione di logica tra motore esterno, fallback locale e documentale SafeOps; il document-engine va allineato per non usare template/logo Extra come default.

Priorita consigliata

1. Formazione
2. audit separato, perche' ha gia un modello branding proprio e flussi WooCommerce.

Decisioni mancanti

• Le NC devono essere sempre archiviate nel documentale o solo quando l'utente clicca "salva"?
• La bozza RAS deve diventare identica al finale verticale o restare DOCX modificabile?
• IDS-A resta una demo interna o diventa output ufficiale?
• Le offerte RAS devono passare sempre dal document-engine o SafeOps deve avere fallback ufficiale versionato?

Prossimo passo operativo

Validare graficamente il branding Offerte/preventivi RAS sui tenant reali:

• rendere il branding sempre tenant-aware;
• verificare Safecondo e Besant;
• decidere se la preview inline deve anche consolidare una versione.