> ## Documentation Index > Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt > Use this file to discover all available pages before exploring further. # Flusso e Regole di Approvazione > Come una modifica passa da sottoposta ad approvata ed eseguita — sia per modifiche standard che per patch di aggiornamento — e come governare chi deve approvare cosa. import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components'; L'approvazione è il cuore della Gestione delle Modifiche. Qualsiasi cosa che alteri un sistema passa attraverso un **gate umano** prima di essere eseguita — che sia una modifica standard scritta a mano o un lotto di patch di sistema operativo. Questa pagina copre quel gate dall'inizio alla fine e come governarlo con le **regole di approvazione**. ## Il Gate, Passo per Passo L'autore termina la bozza e la **sottopone**. La modifica passa a *Sottoposta* e la [regola di approvazione](#regole-di-approvazione) corrispondente determina chi deve firmare e quante approvazioni servono. Gli approvatori aprono la modifica, revisionano giustificazione, rischio, finestra e piano, e **Approvano** o **Rifiutano**. Il pannello delle **Approvazioni** traccia il progresso in tempo reale — per esempio *2 di 3* — e mostra quale regola è in vigore. Raggiunto il numero richiesto di approvazioni, la modifica diventa *Approvata* ed è pronta per essere eseguita. Una **modifica standard** viene avviata esplicitamente con **Execute** (Approvata → In esecuzione), e gli agenti eseguono i passaggi. Una **patch di aggiornamento** non ha bisogno di trigger manuale — si **installa automaticamente all'interno della sua finestra di manutenzione pianificata**. La modifica termina come *Completata* (o *Parziale* / *Fallita*), e tutta la traccia decisionale è registrata nella sua cronologia. ### Approvare e rifiutare * **Approvare** registra la tua decisione sotto il tuo utente. Quando la modifica raggiunge il numero richiesto di approvazioni, avanza automaticamente. * **Rifiutare** termina il flusso di approvazione — la modifica passa a *Rifiutata*. Puoi allegare una **motivazione** così che l'autore sappia cosa correggere; può poi modificare la modifica (che la riporta a *Bozza*) e sottoporla di nuovo. Ogni approvazione e rifiuto è attribuito all'utente che l'ha fatto, con un timestamp, e appare nella cronologia di **Attività** della modifica — così che il record risponda "chi ha approvato questo, e quando?" da solo. ## I Due Percorsi di Esecuzione Il gate di approvazione è identico per entrambi i tipi di modifica; differisce solo ciò che accade *dopo l'approvazione*. Dopo l'approvazione, una persona clicca **Execute** per avviare la modifica. Questo mantiene un umano nel controllo di *quando* il lavoro inizia, anche dopo la firma. Gli agenti eseguono poi i passaggi di implementazione dal Workspace, e il piano di rollback è a portata di mano se necessario. Approvare un gruppo di patch **autorizza l'agente a installarlo nella prossima finestra di manutenzione**. Non c'è Execute manuale — il rollout inizia quando la finestra si apre e procede elemento per elemento. Approvare è registrato sotto il tuo utente. Per le patch, approvare è l'impegno. La conferma è esplicita: *"Questo autorizza l'agente a installare gli aggiornamenti di questo gruppo nella prossima finestra di manutenzione."* Fino ad allora, la vista delle patch in sospeso è di sola lettura e non installa nulla. ## Regole di Approvazione Di default, una modifica richiede **un'approvazione, e il richiedente può approvare la propria modifica**. Va bene per un piccolo team, ma la maggior parte delle organizzazioni vuole una governance più forte. Le **regole di approvazione** ti permettono di definire, per [contesto](/it/documentation/get-started/concepts#how-your-account-is-organized), esattamente chi deve approvare quali modifiche — una policy valutata automaticamente ogni volta che una modifica è sottoposta. Una regola è composta da: | Impostazione | Cosa fa | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nome** | Un'etichetta per la regola. | | **Tipo di modifica** | A quali modifiche la regola si applica — **standard**, **normal** o **emergency**. Lascia vuoto per applicarla a **tutte le modifiche**. | | **Minimo di approvazioni** | Quante approvazioni sono richieste prima che la modifica possa avanzare. | | **Approvatori nominati** | Un elenco esplicito di utenti che possono approvare — solo loro contano per il minimo. Vuoto significa **qualsiasi approvatore**: chiunque sia autorizzato ad approvare in quel contesto. | | **Attiva** | Una regola può essere accesa o spenta senza essere eliminata. | Quando una modifica è sottoposta, Myrmex trova la regola corrispondente (per tipo di modifica, preferendo una regola nominata per quel tipo a una generica) e la applica. Il pannello delle **Approvazioni** mostra poi la regola in vigore e il progresso verso il suo minimo — per esempio, *min. 2*. Le regole sono un livello di policy, non un collo di bottiglia: se nessuna regola corrisponde a una modifica, si applica il **default** — 1 approvazione, e il richiedente può approvare. Rimuovere una regola fa semplicemente ricadere le sue modifiche su quel default. ### Gestire le regole Apri la vista **Regole di approvazione** dalla Gestione delle Modifiche per creare, modificare, abilitare/disabilitare o eliminare regole. Gestire le regole è un'azione di governance, separata dall'approvare singole modifiche — è gated dal permesso `gmuds.admin`. Eliminare una regola non blocca nulla — le modifiche nel suo ambito ricadono sulla policy di default (1 approvazione, il richiedente può approvare). Se hai bisogno di un controllo più rigido, disabilita una regola invece di lasciare un vuoto, o sostituiscila prima di rimuoverla. ## Chi Può Fare Cosa La Gestione delle Modifiche è governata da un insieme dedicato di permessi, così puoi separare chi *redige* le modifiche da chi le *approva* e chi *governa le regole*: | Permesso | Concede | | --------------- | -------------------------------------------------------------------------- | | `gmuds.read` | Visualizzare modifiche, i loro passaggi e le regole di approvazione. | | `gmuds.create` | Creare nuove richieste di modifica. | | `gmuds.update` | Modificare le modifiche, sottoporre per approvazione e gestire i passaggi. | | `gmuds.approve` | **Approvare o rifiutare** modifiche sottoposte. | | `gmuds.delete` | Eliminare le modifiche. | | `gmuds.admin` | **Amministrare le regole di approvazione** (governance). | Concedi `gmuds.create` / `gmuds.update` agli ingegneri che pianificano le modifiche, riserva `gmuds.approve` ai proprietari delle modifiche o a un comitato di approvazione, e tieni `gmuds.admin` con il tuo team di governance. Combinato con gli **approvatori nominati** in una regola, ti dà una separazione dei compiti pulita. Vedi [Controllo degli accessi](/it/documentation/management/access-control). ## Correlato Il modulo, i due tipi di modifica e il ciclo di vita completo. Consulta gli aggiornamenti in sospeso e approva le pianificazioni di patch proposte dall'IA.