Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How do I expose the date an issues moved to each status?

I need to show how long issues are worked within a few projects. I created a filter that shows all data needed except when the developer began work on an issue. I only need expose the date the status became 'In Progress' for each issue. The Resolved date was available in the Columns dropdown. The created date does not give the actual start date. 

Any help is appreciated!

2 answers

1 accepted

1 vote
Answer accepted

I think one of the reporting weaknesses in JIRA is that there's really nothing that can tell you about the date/times of status changes.  The information is recorded in the data that is the issue history, and you can see it in there for any individual issue, but there's nothing that reports on it for a collection of issues.

On server JIRA, I'd add the Script Runner add-on and then use it to create a simple custom field that shows the date/time of the transition I was interested in.  You can do something similar with a date/time field on Cloud that the Scripr Runner for Cloud can populate (it's not the same as a Server scripted field, but it will do the job)

Thanks Nic. I was hoping I was missing something obvious. Our department moved to JIRA on my recommendation but apparently I overlooked this crucial aspect. Everything else has been so intuitive that I thought I must be overlooking something. I will look into Script Runner for Cloud.

Hello There 
Can I attach the current status of the issue in each comment made on it ??

With scripting, yes.  But that would make the comments polluted and long.

could you please tell me how ??

You will need to get something like Script Runner, which can create "scripted listeners" - a listener will need to catch all the "issue commented" events, read the current status and append it to the last comment.

At a basic level this is inconsequential. However, every time a customer has come to me with this use-case they've presented unique needs that didn't align with other customer needs. I think this is a challenging use-case because it doesn't work well out-of-the-box. A basic implementation uses logic and out-of-the-box custom fields. Let's work this out here on Answers.

Before continuing, let's dissect the behavior of the system fields. 

  1. Created is a Date/Time Field set upon the original creation of the issue. It is never cleared.
  2. Resolved is a Date/Time Field set when the issue has a Resolution applied to it, typically on transitions leading to Completed (green) statuses. It is cleared when the Resolution field is cleared.


Now, we have several transitions or actions that we need to record time-of-action for – 

image2017-1-1 14:48:56.png

  • Create (Already handled by the Created system field)
  • Start progress
  • Stop progress
  • Done (Already handled by the Resolved system field.)
  • Reopen
  • Reopen and start progress


We can capture this data in Date/Time Custom Fields, so we might want to create all the fields we need to for a given workflow.

  • Work Started
  • Work Stopped
  • Reopened


Using a transition post-function such as Update Issue Custom Field, we can set the date/time fields to "current time" when a transition is committed. 

  • Start progress
    • Update Issue Custom Field – 
      Work Started
  • Stop progress
    • Update Issue Custom Field – 
      Work Stopped
  • Reopen
    • Update Issue Custom Field – 
  • Reopen and start progress
    • Update Issue Custom Field – 
      Work Started


The raw dates are available for query and are reportable. Visually our data is in a format like so –

image2017-1-1 15:3:40.pngimage2017-1-1 15:6:35.png


Lackluster? Sure! But I think it get's the job done remarkably easily. This might be more efficient to implement as a listener, for ScriptRunner customers.

Hi Steven - I am trying to implement your answer and getting stuck between creating the custom fields and making them available as a Update Issue Custom Field selection in the Issue Field: dropdown. I am very new to JIRA and still sorting out the whole screen/scheme associations.Screen Shot 2017-01-02 at 12.25.03 PM.png

That post-function only sets system fields, you need to use the "update custom field" post-function Steven mentions.

I only see Update Issue Field as an option.

Ah, you'll need to make sure you have the add-on that provides it enabled in your my.Atlassian account for your Cloud system.

It seems all the add-ons are for server only.

I'm sorry, I hadn't considered that. 

That post-function is provided by the JIRA Suite Utilities add-on, which as far as I know is still pre-installed and provided free-of-charge to JIRA Cloud customers.

image2017-1-2 11:18:38.png

Can you navigate to Manage Add-ons and check to see if JIRA Suite Utilities is activated? It may be deactivated and you may need to contact Atlassian Support to enable that add-on for the Update Issue Custom Field post-function.

Yes, I see JIRA Suite Utilities, but it is grayed out. I am contacting support now.

JIRA Suite Utilities was activated and now I have been able to follow the instructions and create the necessary reporting. Brilliant! Thanks for the help Steven!

Excellent, I am glad that this process works well for you. smile Good luck and happy new year!

This is great - exactly what I've been looking for. Just a shame Atlassian don't expose the start date as standard like they do the resolved date and a shame that you have to pay for an additional plugin to get something as basic as this out of it. 

I have a follow-on question though. Once you get the date - it's in the following format "2017-02-04T14:33:46.000+0002" - how can you do any calculations with this date format in e.g. Google sheets as it doesn't seem to be a standard date format that can have formulas applied to it ? 



Since I've written this post, whoever vends JSUtilities has made the plugin, free for years and years, paid. I'm particularly sore about it and am in the process of removing it from my system.

Keep in mind the original source code (which needs updating) is still available online. If I didn't have Scriptrunner, I'd probably update it for myself.

It would appear that you missed a step of my guide - 

We can capture this data in Date/Time Custom Fields, so we might want to create all the fields we need to for a given workflow.

It sounds like you're using a 'Text field' to capture the output. I'm sure this is just giving you a string representation of the Timestamp or Date or whatever class Jira uses. If you output that value instead to a custom field of type Date/Time you will capture the data which will respect your Jira's date settings/export settings. The text field is plaintext is prints whatever it's exact value and is not interpreted at run time unless you apply a new renderer and is not interpreted at export time.

Suggest an answer

Log in or Sign up to answer