Time Tracking Automation Smart Value

[Alex Burns]

Hi all, I'm currently trying to use an automated process whereby when a user moves a task from "In Progress" to either "To Do" or "Done", their time is automatically logged in the Time Tracking property.

I'm trying to use this but it always returns 0:

{{issue.statuscategorychangedate.toDate.diff(now).minutes}}

Thanks

[Pasam Venkateshwarrao · Accepted solution]

Hi @Alex Burns 

Welcome to the community, you can follow these steps 

1. Add the 'Issue transitioned' trigger & select a from and to status
2. Now you should have a place were you can keep the time you want to capture. I advice you to use Jira issue properties. One for start time, one for total time spent.
   Create an action of type 'set entity property'
   property key: startTime
   property value: {{now}}
   See for smart time based values: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/
3. Save the rule
4. Create another rule with an 'Issue transitioned' trigger, but now when you move out of the status
5. For now, use a Log action, to see if things are working. Later you can use the variable in a Jira field to store it (or automatically create a worklog of it).
   In the log add smart value:
   {{issue.properties.startTime.toDate.diff(now).minutes}}
6. Save the rule

[Alex Burns]

This works perfectly, thank you for your help!

[Vishal Biyani]

@Alex Burns with toDate you need to specify the date format.

{{issue.statuscategorychangedate.toDate("yyyy-MM-dd").diff(now).minutes}}

[Bill Sheboy]

Hi @Vishal Biyani 

The toDate function only needs the help of a specific format expression when the date or date / time is in an ambiguous or non-standard format: https://support.atlassian.com/cloud-automation/docs/examples-of-using-smart-values-with-dates/#Converting-text-to-dates

Otherwise, it will will succeed with standard formats such as jiraDate, jiraDateTime, etc.

The root cause of the original poster's error was using statusCategoryChangedDate after it had already changed value rather than when the category last changed.

Kind regards,
Bill

[Vishal Biyani]

Hi @Bill Sheboy 

Thanks for pointing out the .toDate part. My bad that I didn't test this myself before putting on the forum.

For your second point (root cause), I am not clear. Could you please elaborate?

My understanding

When issue is transitioned from say "In Progress" to "To Do", then statuscategorychangedate will give the time when issue status changed to "To Do". is my understanding correct?

However, I do understand that as soon as transition happens automation rule will trigger and in 99.99% cases statuscategorychangedate and now will have same value and hence this calculation with will most likely return 0?

So, would using the approach that Pasam mentioned in steps 1 & 2 would give the time when issue came in status "In Progress"?

Regards,

Vishal

[Bill Sheboy]

Yes, and...

First thing: I would not recommend automatically tracking / logging time this way.  It assumes two things that may not be valid: people correctly transition issues as-soon-as work starts / stops, and logging calendar / clock time is what is desired (rather than actual working time).

And, you are correct the statusCategoryChangedDate contains when the most recent status category changed.  When one wants to implement what the original poster requested, they would use a more sophisticated rule, with multiple custom fields: the previous status category and the previous status category changed date / time.  However this is implemented, the rule will get complicated quickly with the number of conditions / scenarios required.  One possible approach could be:

• trigger: on transition
• if / else condition
  • smart value condition to check if the "previous status category" is empty
  • action: edit issue, setting...
    • "previous status category" to the current value
    • "previous status category changed date / time" to the current value
• else / if 
  • smart value condition to check if the "previous status category" differs from the current value
  • ??? decide what to do based on the current and previous values (see below)

One would need to decide which cases to cover, including how to handle people incorrectly transitioning issues.  For example:

                     New Status Category  
Old Status Category  To Do    In Progress  Done
-------------------  -----    -----------  -------
To Do                X        start clock  measure
In Progress          measure  X            measure
Done                 valid?   valid?       X

[Vishal Banshraj Gupta]

Hi Alex, 

Could you provide a specific example of what you need when a user changes the issue status from "In Progress" to any other status?