smart value displaying the status change

[Estelle Decanis]

Hi,

I use an automation whose trigger is the change of transition from status A to status B. I want to display the date of change to status B in a field. I had done this :

{{issue.statuscategorychangedate.toDate.jiradate}}

It works very well, it sends me the date of change of status category.

But I want to display the date of the status change. I would like to apply this :

{{issue.statuschangedate.toDate.jiradate}}

Someone would have an idea ?

Best regards,

Estelle

[Bill Sheboy · Accepted solution]

Hi @Estelle Decanis 

That is not possible with out-of-the-box features; only the status category has built-in tracking which is easily accessible.

Your work-around options are impacted by your cost/easy of use factors:

• cost to build/maintain, and easy to use
  • add custom fields to track your desired status change date/times (by status), and use an automation rule to update them.  Note you will need to decide if this should be the first change, last change, etc.
• cost to build/maintain, and ease is subject to your solution
  • all of the issue history is available, and it is accessible from the UX or from the REST API, so you could build an app which calls the REST API to gather this information
• license costs, and pre-built
  • investigate the Atlassian Marketplace to purchase addon apps for this

Kind regards,
Bill

[Estelle Decanis]

thank you for your answer @Bill Sheboy 

[Estelle Decanis · Accepted solution]

as it is at status change this smart value works : (and avoids code or purchase)

{{issue.updated.jiradate}}

[Bill Sheboy]

Please note the updated field will note any changes, not just status transitions.  So that field will also change for field edits, comments, etc.

[Estelle Decanis]

Yes of course, it's important to specify it.

I didn't put the automation but it will be clearer :

The trigger is a defined transition. At that moment the smart value with the update date will be applied.
And as the trigger is a defined transition the other updates of the ticket will not trigger the smart value.

[Bill Sheboy]

Thanks for explaining, and that is a good work-around!

With automation rules, there is a small-ish chance the updated date/time could still be after the actual transition change...this could happen when automation rule execution is delayed (e.g. automation engine performance in the cloud) and there was another update later (e.g. field edit).  Just wanted to note that in case you see differences between your custom field and the issue's history.

[Estelle Decanis]

Thanks for your clarifications. It is always very useful

[Mariana_Pryshliak_Saasjet]

Hello @Estelle Decanis 

To get the status changed date, you can try Time in Status for Jira Cloud from the Atlassian Marketplace. It generates a Status Entrance Date report, that shows the date when an issue has entered each of the statuses. So you'll get an accurate data of status transitions.

You can export data as CSV and XLSX files for further analysis.

 It's developed by my team and is free for using up to 10 users. Please, let me know if you have any questions.

Hope it helps.

[Estelle Decanis]

ok thanks

[zacharoula_brinia]

@Estelle Decanis Great reply. I would like to see the Deployments dates. I have created a custom field for the dev's tasks "Deployment Date" and I have created an automation rule. My columns are per status for the tasks e.g. In Progress, Deployed to Test, Deployed to Live, etc. How can I be sure that the Deployment Date field will be auto-filled with the updated status date (e.g. Deployed to Live) and not with any further change?

Can you help me, please?

Thank you.

FYI, this is the current status of my rule:
Which one might work? If none of them what would you suggest?

[Yehoshua Silberstein]

I am a little confused. Wouldn't just using the smart value of {{now}} work? You'd be saying when the transition happens, set that date in the field.

[Bill Sheboy]

Hi @Yehoshua Silberstein 

Yes, and that was what was suggested by many of the posts here.  Some were variations on that theme, based on either simpler workflow (i.e. one status per category) or no other changes close in time (e.g. checking updated)

Kind regards,
Bill