How to identify the author of a global status change in Jira
Hi Community!
I recently came across a situation from a client that ignited my curiosity and helped me learn something new that I would like to share with the community.
Client request
I see that the project workflow scheme has changed. There is now a "Budget Approved" status instead of the "Approved." Is this a bug, or is there a user that made this change?
Can you imagine how many problems an "inoffensive" change in status name can cause in a Jira instance? Right of the bat, I can see dashboards and reports that use the status name on JQL's stopping to give the right results. But I am sure it does not stop here.
Analysis
Even though Jira prompts the alert - "This status is used in other workflows, editing it will affect them." - a naive Jira Administrator might skim the message and perform the change. And then the warm is already done.
When prompted with this customer request, my instinct drove me to search for the root cause in the Audit Log. Surprisingly, I discovered that the Audit Log does not register global status changes (here is a suggestion JRASERVER-70388 under consideration).
Since the Jira Administrator who executed this change did so for a reason, just renaming the status back to "Approved" would solve this incident and disrupt another workflow.
So here is my thought process to find who made the change and ensure that another workflow does not break.
- Identify all workflows that use the now renamed "Budget Approved" status in JIRA_BASE_URL/secure/admin/ViewStatuses.jspa
- Investigate the Last modified column on JIRA_BASE_URL/secure/admin/workflows/ListWorkflows.jspa to find the date and user who did the lastest change on the workflows from step 1
- Filter the Author in the Audit Log with one user from step 2
- There might be many entries, so search for the workflow name from step 1 on the Affected object (s) page.
- If you don't find anything, repeat steps 3 to 4 for other users.
- After a couple of iterations, voila!
I can say that I got lucky that this change was executed as part of a workflow change. Therefore, Jira logged the statuses removed and added.
For a status change executed in JIRA_BASE_URL/secure/admin/ViewStatuses.jspa, there will not be any entry in the Audit Log. Let's vote for JRASERVER-70388 !
Conclusion
With this information in mind, I could reach out to the Jira Administrator to create a new status and ensure that both workflows will be working as expected by users.
I hope it could give some additional insights on troubleshooting, and if you have any other experience in troubleshooting this type of change please comment.
Cheers,
Alex