Relatório de alterações (exportação delta)
A maioria das exportações responde a «como isto está agora?». Um relatório de alterações responde à pergunta que as pessoas realmente fazem numa reunião de acompanhamento: «o que mudou desde a última vez?»
Disponível no Standard para exportações JQL, de quadro, sprint, versão e backlog. Ele rende mais como exportação agendada: um relatório semanal de «o que mudou» que chega à caixa de entrada na segunda-feira de manhã.
O que ele não é
Não é um despejo do log de alterações do Jira. Para isso já existe o componente Histórico de alterações, que trabalha item a item.
Um relatório de alterações trabalha no nível do conjunto exportado:
- quais itens surgiram,
- quais itens não estão mais no resultado,
- quais itens mudaram — status, responsável, prioridade, data de vencimento e qualquer campo que você adicione,
- novos comentários e registros de trabalho.
«Não está mais no resultado» não significa excluído
Este é o ponto mais importante a entender sobre o relatório.
Quando um item aparece em Não está mais no resultado, ele deixou de fazer parte do conjunto de resultados da exportação. Isso não significa que o item foi excluído. Ele pode ter sido movido para outro projeto, reatribuído, reetiquetado ou simplesmente editado de modo que o filtro não o encontre mais.
Toda lista de itens que saíram traz essa observação no documento exportado, em todos os idiomas e formatos, e a compactação nunca a remove. Um relatório que afirmasse que um trabalho foi excluído quando ele apenas foi reetiquetado seria um mal-entendido caro.
Pelo mesmo motivo, os itens que saíram são listados apenas pela chave. O Exportelier não guarda cópia deles, e consultar seu estado atual nada diria sobre o motivo da saída.
Configuração
- Abra o modelo no designer.
- Ative Relatório de alterações e escolha um ponto de referência.
- Posicione os três componentes:
- Resumo de alterações — os contadores, a linha de referência e as observações.
- Lista delta de itens — uma lista, definida como Adicionados ou Não estão mais no resultado. Adicione duas vezes para ambos.
- Tabela de alterações — uma linha por campo alterado.
- Salve e use o modelo como qualquer outro.
Pontos de referência
| Referência | Significado | Use para |
|---|---|---|
| Exportação anterior | A última vez que este modelo exportou este escopo | Relatórios pontuais |
| Execução agendada anterior | A última execução bem-sucedida deste agendamento | Relatórios semanais e mensais |
| Data fixa | Uma data que você informa | «Tudo desde a criação do branch de versão» |
Campos monitorados
Status, responsável, prioridade e data de vencimento são sempre monitorados. Acrescente os seus — pontos de história, sprint, um campo personalizado — nas configurações do modelo. Novos comentários e registros de trabalho também contam como alterações e podem ser desativados se forem ruído para o seu público.
A primeira execução
O primeiro relatório para um modelo e um escopo não tem com o que se comparar. Em vez de falhar, ele produz um relatório completo do conjunto atual e informa isso:
Este é o primeiro relatório de alterações para este modelo e este escopo, portanto lista o conjunto atual completo. Os relatórios seguintes mostrarão apenas o que mudou.
A partir da segunda execução você obtém um delta real.
Um exemplo prático
Uma equipe executa uma exportação agendada toda segunda-feira às 08:00 sobre project = EX AND sprint in openSprints(), com os três componentes e a referência Execução agendada anterior.
Segunda, 3 de agosto — primeira execução. Não existe execução anterior, então o relatório lista todos os 14 itens do sprint e traz a observação de primeira execução. É a linha de base.
Durante a semana. EX-104 é criado e puxado para o sprint. EX-77 é movido para outro projeto e sai do filtro. EX-42 percorre To Do → In Progress → Review → In Progress → Review → Done em cinco dias. EX-51 passa de Ada para Grace e recebe dois comentários. Dez itens permanecem intocados.
Segunda, 10 de agosto — segunda execução. O relatório começa com:
Alterações desde 3 de agosto de 2026
Adicionados: 1 · Não estão mais no resultado: 1 · Alterados: 2 · Sem alteração: 10
E então a tabela de alterações:
Chave Campo De Para Alterações EX-42 status To Do Done 5 EX-51 responsável Ada Grace 1
Repare na linha EX-42. Esse item mudou de status cinco vezes, e é uma única linha mostrando onde começou, onde terminou e quantas etapas foram necessárias. Cinco linhas separadas para um item soterrariam os dois itens que realmente exigem atenção.
Tempo de leitura: cerca de quinze segundos, em vez de percorrer quatorze descrições para descobrir o que mudou.
Quando o histórico não pode ser reconstruído
O Jira não registra uma entrada de alteração para todos os campos, e históricos muito longos são truncados ao serem obtidos. Quando o histórico disponível não cobre todo o período do relatório, o item é informado como não reconstruível no resumo, em vez de ser silenciosamente contado como sem alteração.
Subtarefas e níveis de hierarquia mais profundos não têm histórico próprio e caem no mesmo grupo. Eles continuam contando nos totais: o delta sempre trabalha sobre o conjunto plano de itens exportados, de modo que os números fecham.
O que o Exportelier armazena
Para dizer o que foi adicionado e o que saiu, o Exportelier precisa lembrar quais itens estavam na exportação anterior. Ele armazena as chaves dos itens, e nada mais.
Nenhum resumo, nenhum valor de campo, nenhuma descrição, nenhum comentário. Os valores antes e depois na tabela de alterações são lidos do próprio histórico do Jira no momento da geração do relatório e nunca são mantidos. A lista de chaves armazenada expira após 180 dias.
É uma decisão deliberada: guardar valores de campo tornaria o relatório mais simples de construir, mas faria do Exportelier uma segunda cópia do seu conteúdo do Jira, com tudo o que isso implica para a proteção de dados.
Limites
- Indisponível para exportações de um único item — use o componente Histórico de alterações.
- Indisponível para arquivos ZIP com um arquivo por item: um relatório sobre todo o conjunto não tem um documento único onde ficar.
- São lembradas até 2.000 chaves por modelo e escopo. Acima disso, o relatório avisa que as contagens de adicionados e de saídas podem estar incompletas.
- A tabela de alterações é limitada a 500 linhas por relatório; se o limite for atingido, o documento informa.