Vai al contenuto

Controllo incarico RAS unico — 9 settembre 2026

Implementato e attivato sul servizio safeops-web.service, riavviato alle 18:33 Europe/Rome. Verifica successiva: servizio active, GET /login/ con Host Safecondo HTTP 200. Il primo probe durante il bootstrap era scaduto.

Regola

La tabella commerciale_tecnico_incarico consente, nei percorsi ORM applicativi, un solo incarico RAS non archiviato per tenant e cliente. Il riconoscimento RAS considera origine richiesta_ras, codice servizio RAS/RAS_* e workflow ras_quote. Chiuso, annullato, sospeso e rifiutato continuano a occupare il posto. Solo archiviato lo libera.

La scelta Archiviato e disponibile nei moduli incarico e nel cambio stato; il cambio stato richiede una nota e mantiene il consueto audit. Gli incarichi archiviati non possono essere accettati tramite la risposta del tecnico. La riattivazione tramite cambio stato e sottoposta al controllo. L'archiviazione nella console IDS Extra resta distinta.

Il listener before_flush blocca nuove righe, riattivazioni e cambi di condominio/tenant/servizio che produrrebbero duplicati. Serializza gli scrittori bloccando la riga cliente e legge gli incarichi con FOR UPDATE, anche con MySQL REPEATABLE READ. Considera tutte le modifiche pendenti, comprese archiviazione e sostituzione nella stessa transazione. Gli errori gestiti restituiscono un messaggio con gli incarichi coinvolti; il gestore HTTP effettua rollback e restituisce 409.

L'upsert da richiesta recupera l'incarico originario anche quando il payload non ne contiene l'ID, verifica la coerenza del collegamento e non riattiva implicitamente un incarico archiviato.

Verifiche e limiti

  • 22 test passati in database SQLite isolato, senza bootstrap applicativo.
  • Verificata generazione dei lock SQL per MySQL e PostgreSQL; non eseguito uno stress test concorrente sul database di produzione.
  • Test anche su upsert reale estratto dal modulo, puntatore mancante, puntatore estraneo, archiviato, rollback HTTP e duplicati storici.
  • Sintassi Python e template Jinja valida; diff check senza errori.
  • Nessuna migrazione o bonifica dati eseguita: Glicini e Orano non sono stati riassegnati, riaperti o archiviati da questo intervento.
  • Il controllo riguarda i salvataggi ORM della tabella incarichi commerciale; SQL diretto e bulk SQL esterni non sono vincolati da un indice nel DB.
  • Le modifiche preesistenti nella workspace sono state preservate.

Guida aggiornata: manuale_operativo_tecnico_ras_compila.md, sezione “Un solo incarico RAS per condominio”, e note contestuali nei moduli.

change_summary: blocco duplicati RAS e archiviazione esplicita incarico
user_impact: un secondo RAS richiede archiviazione del precedente
roles_impacted: operatori incarichi, tecnici, IDS, amministratori tenant
surfaces_impacted: creazione incarichi, cambio stato, risposta tecnico, upsert RAS
behavior_change: si
permission_change: no nuovi permessi
operator_action_required: archiviare esplicitamente prima di un nuovo ciclo
helper_impact: helper_update_required
helper_content_type: procedure
release_severity: L3
helper_ready_for_release: true
block_release: false
block_reason: guida e note contestuali aggiornate; verifiche passate