Wijzigingsrapport (delta-export)
De meeste exports beantwoorden de vraag «hoe ziet dit er nu uit?». Een wijzigingsrapport beantwoordt de vraag die mensen in een voortgangsoverleg werkelijk stellen: «wat is er sinds de vorige keer veranderd?»
Beschikbaar in Standard voor JQL-, bord-, sprint-, release- en backlog-exports. Het komt het best tot zijn recht als geplande export: een wekelijks rapport dat maandagochtend in uw postvak ligt.
Wat het niet is
Het is geen uitdraai van het wijzigingslogboek van Jira. Daar is het component Wijzigingsgeschiedenis al voor, en dat werkt per issue.
Een wijzigingsrapport werkt op het niveau van de geëxporteerde set:
- welke issues zijn verschenen,
- welke issues niet meer in het resultaat zitten,
- welke issues zijn veranderd — status, toegewezen persoon, prioriteit, vervaldatum en elk veld dat u toevoegt,
- nieuwe opmerkingen en werkregistraties.
«Niet meer in het resultaat» betekent niet verwijderd
Dit is het belangrijkste om over dit rapport te begrijpen.
Wanneer een issue onder Niet meer in het resultaat verschijnt, maakt het geen deel meer uit van de resultaatset van de export. Het betekent niet dat het issue is verwijderd. Het kan naar een ander project zijn verplaatst, opnieuw toegewezen, opnieuw gelabeld of simpelweg zo bewerkt dat uw filter het niet meer vindt.
Elke lijst met vertrokken issues draagt deze notitie in het geëxporteerde document, in alle talen en alle formaten, en compactie verwijdert die nooit. Een rapport dat beweert dat werk is verwijderd terwijl het alleen opnieuw is gelabeld, zou een duur misverstand zijn.
Om dezelfde reden worden vertrokken issues alleen met hun sleutel vermeld. Exportelier bewaart er geen kopie van, en hun huidige status opvragen zou niets zeggen over waarom ze zijn vertrokken.
Instellen
- Open het sjabloon in de designer.
- Zet Wijzigingsrapport aan en kies een referentiepunt.
- Plaats de drie componenten:
- Wijzigingsoverzicht — de tellers, de referentieregel en notities.
- Delta-issuelijst — één lijst, ingesteld op Toegevoegd of Niet meer in het resultaat. Voeg hem twee keer toe voor beide.
- Wijzigingstabel — één rij per gewijzigd veld.
- Sla op en gebruik het sjabloon als elk ander.
Referentiepunten
| Referentie | Betekenis | Gebruik voor |
|---|---|---|
| Vorige export | De laatste keer dat dit sjabloon dit bereik exporteerde | Losse rapporten |
| Vorige geplande uitvoering | De laatste geslaagde uitvoering van deze planning | Wekelijkse en maandelijkse rapporten |
| Vaste datum | Een datum die u invoert | «Alles sinds de release-branch is afgesplitst» |
Gevolgde velden
Status, toegewezen persoon, prioriteit en vervaldatum worden altijd gevolgd. Voeg uw eigen velden toe — storypoints, sprint, een aangepast veld — in de sjablooninstellingen. Nieuwe opmerkingen en werkregistraties tellen ook als wijziging en kunnen worden uitgeschakeld als ze ruis zijn voor uw publiek.
De eerste uitvoering
Het eerste rapport voor een sjabloon en bereik heeft niets om mee te vergelijken. In plaats van te mislukken maakt het een volledig rapport van de huidige set en zegt dat er ook bij:
Dit is het eerste wijzigingsrapport voor dit sjabloon en dit bereik; het toont daarom de volledige huidige set. Latere rapporten tonen alleen wat er is veranderd.
Vanaf de tweede uitvoering krijgt u een echte delta.
Een uitgewerkt voorbeeld
Een team draait elke maandag om 08:00 een geplande export op project = EX AND sprint in openSprints(), met alle drie de componenten en de referentie Vorige geplande uitvoering.
Maandag 3 augustus — eerste uitvoering. Er is geen eerdere uitvoering, dus het rapport toont alle 14 issues in de sprint met de notitie voor de eerste uitvoering. Dat is de nullijn.
In de loop van de week. EX-104 wordt aangemaakt en in de sprint getrokken. EX-77 verhuist naar een ander project en valt uit het filter. EX-42 doorloopt in vijf dagen To Do → In Progress → Review → In Progress → Review → Done. EX-51 gaat van Ada naar Grace en krijgt twee opmerkingen. Tien issues blijven onaangeroerd.
Maandag 10 augustus — tweede uitvoering. Het rapport begint met:
Wijzigingen sinds 3 augustus 2026
Toegevoegd: 1 · Niet meer in het resultaat: 1 · Gewijzigd: 2 · Ongewijzigd: 10
En daarna de wijzigingstabel:
Sleutel Veld Van Naar Wijzigingen EX-42 status To Do Done 5 EX-51 toegewezen aan Ada Grace 1
Let op de regel EX-42. Dat issue veranderde vijf keer van status, en het is één regel die laat zien waar het begon, waar het eindigde en hoeveel stappen ervoor nodig waren. Vijf aparte regels voor één issue zouden de twee issues bedelven die werkelijk aandacht vragen.
Leestijd: ongeveer vijftien seconden, tegenover het doorscrollen van veertien beschrijvingen om te achterhalen wat er anders is.
Wanneer de geschiedenis niet te reconstrueren is
Jira legt niet voor elk veld een wijziging vast, en zeer lange geschiedenissen worden bij het ophalen afgekapt. Wanneer de beschikbare geschiedenis de hele rapportageperiode niet dekt, wordt het issue in het overzicht gemeld als niet reconstrueerbaar in plaats van stilzwijgend als ongewijzigd te worden geteld.
Subtaken en diepere hiërarchieniveaus hebben geen eigen wijzigingsgeschiedenis en vallen dus in dezelfde groep. Ze tellen nog steeds mee in de totalen: de delta werkt altijd op de platte set geëxporteerde issues, zodat de cijfers kloppen.
Wat Exportelier opslaat
Om te kunnen zeggen wat is toegevoegd en wat is vertrokken, moet Exportelier onthouden welke issues in de vorige export zaten. Het slaat de issuesleutels op, en niets anders.
Geen samenvattingen, geen veldwaarden, geen beschrijvingen, geen opmerkingen. De voor- en nawaarden in de wijzigingstabel worden op het moment van genereren uit de eigen wijzigingsgeschiedenis van Jira gelezen en nooit bewaard. De opgeslagen sleutellijst verloopt na 180 dagen.
Dat is een bewuste keuze: veldwaarden bewaren zou het rapport eenvoudiger maken, maar zou van Exportelier een tweede kopie van uw Jira-inhoud maken, met alle gevolgen van dien voor gegevensbescherming.
Limieten
- Niet beschikbaar voor exports van één issue — gebruik daar het component Wijzigingsgeschiedenis.
- Niet beschikbaar voor ZIP-archieven met één bestand per issue: een rapport over de hele set heeft geen enkel document om in te staan.
- Er worden tot 2.000 issuesleutels onthouden per sjabloon en bereik. Daarboven meldt het rapport dat de aantallen toegevoegd en vertrokken onvolledig kunnen zijn.
- De wijzigingstabel is beperkt tot 500 rijen per rapport; wordt die grens bereikt, dan meldt het document dat.