Report delle modifiche (esportazione delta)
La maggior parte delle esportazioni risponde alla domanda «com'è la situazione adesso?». Un report delle modifiche risponde alla domanda che si pone davvero in una riunione di avanzamento: «cosa si è mosso dall'ultima volta?»
Disponibile in Standard per esportazioni JQL, di bacheca, sprint, versione e backlog. Dà il meglio come esportazione pianificata: un report settimanale «cosa si è mosso» che arriva in casella di posta il lunedì mattina.
Cosa non è
Non è un riversamento del registro modifiche di Jira. Per quello esiste già il componente Cronologia modifiche, che lavora ticket per ticket.
Un report delle modifiche lavora a livello dell'insieme esportato:
- quali ticket sono comparsi,
- quali ticket non sono più nel risultato,
- quali ticket si sono mossi — stato, assegnatario, priorità, data di scadenza e qualsiasi campo tu aggiunga,
- nuovi commenti e log di lavoro.
«Non più nel risultato» non significa eliminato
È la cosa più importante da capire di questo report.
Quando un ticket compare sotto Non più nel risultato, significa che non fa più parte dell'insieme di risultati dell'esportazione. Non significa che sia stato eliminato. Può essere stato spostato in un altro progetto, riassegnato, rietichettato o semplicemente modificato in modo che il filtro non lo trovi più.
Ogni elenco di ticket usciti riporta questa nota nel documento esportato, in tutte le lingue e in tutti i formati, e la compattazione non la rimuove mai. Un report che sostenesse che del lavoro è stato eliminato quando era stato solo rietichettato sarebbe un fraintendimento costoso.
Per lo stesso motivo, i ticket usciti sono elencati solo per chiave. Exportelier non ne conserva alcuna copia, e recuperarne lo stato attuale non direbbe nulla sul motivo dell'uscita.
Configurazione
- Apri il modello nel designer.
- Attiva Report delle modifiche e scegli un punto di riferimento.
- Posiziona i tre componenti:
- Riepilogo modifiche — i contatori, la riga di riferimento e le note.
- Elenco delta dei ticket — un elenco, impostato su Aggiunti o Non più nel risultato. Aggiungilo due volte per entrambi.
- Tabella delle modifiche — una riga per ogni campo modificato.
- Salva e usa il modello come qualsiasi altro.
Punti di riferimento
| Riferimento | Significato | Da usare per |
|---|---|---|
| Esportazione precedente | L'ultima volta che questo modello ha esportato questo ambito | Report estemporanei |
| Esecuzione pianificata precedente | L'ultima esecuzione riuscita di questa pianificazione | Report settimanali e mensili |
| Data fissa | Una data che indichi tu | «Tutto da quando è stato creato il ramo di rilascio» |
Campi monitorati
Stato, assegnatario, priorità e data di scadenza sono sempre monitorati. Aggiungi i tuoi — story point, sprint, un campo personalizzato — nelle impostazioni del modello. Anche i nuovi commenti e i log di lavoro contano come modifiche e possono essere disattivati se per il tuo pubblico sono rumore.
La prima esecuzione
Il primo report per un modello e un ambito non ha nulla con cui confrontarsi. Anziché fallire, produce un report completo dell'insieme attuale e lo dichiara:
Questo è il primo report delle modifiche per questo modello e questo ambito, quindi elenca l'insieme attuale completo. I report successivi mostreranno solo ciò che è cambiato.
Dalla seconda esecuzione in poi ottieni un delta vero.
Un esempio concreto
Un team esegue un'esportazione pianificata ogni lunedì alle 08:00 su project = EX AND sprint in openSprints(), con tutti e tre i componenti e il riferimento Esecuzione pianificata precedente.
Lunedì 3 agosto — prima esecuzione. Non esiste alcuna esecuzione precedente, quindi il report elenca tutti i 14 ticket dello sprint e riporta la nota di prima esecuzione. È la linea di base.
Durante la settimana. EX-104 viene creato e inserito nello sprint. EX-77 passa a un altro progetto ed esce dal filtro. EX-42 attraversa To Do → In Progress → Review → In Progress → Review → Done in cinque giorni. EX-51 passa da Ada a Grace e riceve due commenti. Dieci ticket restano invariati.
Lunedì 10 agosto — seconda esecuzione. Il report si apre con:
Modifiche dal 3 agosto 2026
Aggiunti: 1 · Non più nel risultato: 1 · Modificati: 2 · Invariati: 10
Poi la tabella delle modifiche:
Chiave Campo Da A Modifiche EX-42 stato To Do Done 5 EX-51 assegnatario Ada Grace 1
Nota la riga EX-42. Quel ticket ha cambiato stato cinque volte, ed è una sola riga che mostra da dove è partito, dove è arrivato e quanti passaggi sono serviti. Cinque righe separate per un solo ticket seppellirebbero i due ticket che meritano davvero attenzione.
Tempo di lettura: una quindicina di secondi, contro lo scorrimento di quattordici descrizioni per capire cosa è cambiato.
Quando la cronologia non è ricostruibile
Jira non registra una voce di modifica per ogni campo, e le cronologie molto lunghe vengono troncate al recupero. Quando la cronologia disponibile non copre l'intero periodo del report, il ticket viene indicato come non ricostruibile nel riepilogo, anziché essere conteggiato silenziosamente come invariato.
Le sottoattività e i livelli di gerarchia più profondi non hanno una cronologia propria e rientrano quindi in questo gruppo. Continuano a contare nei totali: il delta lavora sempre sull'insieme piatto dei ticket esportati, così i numeri tornano.
Cosa memorizza Exportelier
Per dirti cosa è stato aggiunto e cosa è uscito, Exportelier deve ricordare quali ticket erano nell'ultima esportazione. Memorizza le chiavi dei ticket e nient'altro.
Nessun riepilogo, nessun valore di campo, nessuna descrizione, nessun commento. I valori prima/dopo della tabella delle modifiche vengono letti dalla cronologia di Jira nel momento in cui il report viene generato e non vengono mai conservati. L'elenco di chiavi memorizzato scade dopo 180 giorni.
È una scelta deliberata: conservare i valori dei campi renderebbe il report più semplice da costruire, ma farebbe di Exportelier una seconda copia dei tuoi contenuti Jira, con tutto ciò che ne consegue per la protezione dei dati.
Limiti
- Non disponibile per esportazioni di un singolo ticket — usa il componente Cronologia modifiche.
- Non disponibile per gli archivi ZIP con un file per ticket: un report sull'intero insieme non ha un documento unico in cui stare.
- Vengono ricordate fino a 2.000 chiavi per modello e ambito. Oltre tale soglia il report avverte che i conteggi di aggiunti e usciti potrebbero essere incompleti.
- La tabella delle modifiche è limitata a 500 righe per report; se il limite viene raggiunto, il documento lo segnala.