What is your most useful automation ? Here is mine.

[Flavien Gache]

Hi everybody.

I sometimes have automations to set for clients.

I wanted to share one particular automation because I often see people on Community struggling with it and it saved me a lot of time.

Let's say you want to base your story points value on the sum of two other fields : Priority and Impact.

For example, you have the two following fields (with the associated story points) :

Priority => Cascading list with these possible values : Urgent (5), Major (4), Minor (3).

Impact => Cascading list with these possible values : Significant (6), Moderate (2) , Mild (1).

If you want to automate the calculation of the story points, you have to create three rules.

One which will calculate the value of a custom field called PriorityScore. Basically, it will look like this :

When value changed for Priority

If Priority = Urgent

Then update field PriorityScore = 5 (to do this you have to type {{#=}}5{{/}} in the PriorityScore bar)

Else-If Priority = Major

Then update field PriorityScore = 4 (to do this you have to type {{#=}}4{{/}} in the PriorityScore bar)

etc

Another one which will calculate the value of a custom field called ImpactScore. It is the same logic as the previous rule.

A third one which will sum both values and update story points. 

When value changed for (PriorityScore, ImpactScore, Story points)

Then update the story points field : 

{{#=}}{{issue.PriorityScore|0}}+{{issue.PriorityScore|0}}

The |0 determines the default value to avoid problems when some fields are empty.

In the settings for this third rule, don't forget to check the "Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.".

Do you have any easy automation of that kind you often propose to your clients ?

[Guilhem Dupuy]

Hi Flavien !

What a nice automation rule you built there ! It looks pretty neat !

An easy one which is often required by my clients is an automation rule to automatically close an issue when its subtasks are all closed.

It's a pretty easy one, but I though I could share it with you !

Here is an instance of it I use in a Demo project :

Any thoughts ?

[Tom Williams]

Nice use of automation here Flavien. I can see myself using this rule to automatically change the ranking of issues on the backlog. With my Agile hat on, I'd argue though that a Story Point is not a measure determined by Priority and Impact rather consensus in the effort. 

[Bill Sheboy]

Hi, community!  How about Age of WIP (work item age)?

(1) Add a custom numeric field, AgeOfWip

(2) Create the rule with a daily schedule, looking only at "in progress" and non-cancelled items

(3) Edit the custom field to calculate in calendar days

{{#=}}ROUND({{issue.statuscategorychangedate.toDate.convertToTimeZone(reporter.timeZone).diff(now.convertToTimeZone(reporter.timeZone)).millis}} / (1000*60*60*24), 3){{/}}

(4) Add the field to a dashboard, work items, reporting, board colors, etc.

(5) Use Age of WIP to monitor for stalled work, violations of Levels of Service, mis-use of Expedite urgency, etc.

Please look here to learn more about this measure:

https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events

[Flavien Gache]

Very useful indeed. I will remember that ;) Thanks for sharing !

[Kiruthika]

hi @Bill Sheboy - Can you pls let me know if there is any documentation to refer for the formula generation? 

I need to find difference between current date and the "created date" from JIRA

[Kiruthika]

Got the related info from https://support.atlassian.com/jira-software-cloud/docs/smart-values-date-and-time-functions/ 

And Thanks @Bill Sheboy , I'm done with configuring this custom field "Age of tickets" and can now include in various reports.. :) 

[Bill Sheboy]

Hi @Kiruthika 

The link you provided is the one I use for date/time calculations, and the others for text and math are linked on that same page.  For everything else, I end up creating lots of experiment rules with logging to figure things out.  :^)

Please note that some of the date or date/time fields are text and not numeric.  As in my Age of WIP example, those need to be converted to a date first.

Best regards,

Bill

[Elizabeth Dutton]

These are brilliant.  Anyone got any ways of using automation for Jira to transition issues based on Bit Bucket pull requests.  There is functionality on Jira Cloud, but we have Jira Server and moving to Data Center.

[Bill Sheboy]

Hi @Elizabeth Dutton 

Are you able to use incoming webhooks to do that?  Please take a look here for more information for Jira Server/Data Center:

https://confluence.atlassian.com/automation/triggers-993924804.html/#Triggers-incomingwebhookIncomingwebhook

[Bill Sheboy]

How about a no-addons required, histogram plot of issue data?

TL;DR: Using lookup issues, format and RegEx functions, count the issues meeting your criteria. Padding functions add the histogram data points. This works for up to 100 issues (due to the rule execution limit), and can only access the fields within the lookup.

In this example, let's frequency plot the hours issues were created. Here is an example output image.

Experiment to create a histogram of issue create times.
00: 
01: 
02: 
03: 
04: 
05: 
06: 
07: ••••••••••••••••••••••••••••
08: •
09: ••••••••••••••••
10: •••••••••••••••••
11: ••••••
12: •••••••
13: ••••••••••
14: ••••••
15: ••••••
16: •••
17: 
18: 
19: 
20: 
21: 
22: 
23: 

The how-to for the rule is:

• Trigger: scheduled, or can be what you wish
• Action: Lookup Issues with your criteria, such as JQL
• Action: Create Variable with a dummy value, such as {{varEmpty}} set to null
• Action: let's use an HTML formatted email
  • Contents of the email body:

<body>
<div style="font-family:courier">
<p>Experiment to create a histogram of issue create times.<br>
00{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^0$)").split(",").size.plus(2),"•")}}<br>
01{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^1$)").split(",").size.plus(2),"•")}}<br>
02{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^2$)").split(",").size.plus(2),"•")}}<br>
03{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^3$)").split(",").size.plus(2),"•")}}<br>
04{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^4$)").split(",").size.plus(2),"•")}}<br>
05{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^5$)").split(",").size.plus(2),"•")}}<br>
06{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^6$)").split(",").size.plus(2),"•")}}<br>
07{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^7$)").split(",").size.plus(2),"•")}}<br>
08{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^8$)").split(",").size.plus(2),"•")}}<br>
09{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^9$)").split(",").size.plus(2),"•")}}<br>
10{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^10$)").split(",").size.plus(2),"•")}}<br>
11{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^11$)").split(",").size.plus(2),"•")}}<br>
12{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^12$)").split(",").size.plus(2),"•")}}<br>
13{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^13$)").split(",").size.plus(2),"•")}}<br>
14{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^14$)").split(",").size.plus(2),"•")}}<br>
15{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^15$)").split(",").size.plus(2),"•")}}<br>
16{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^16$)").split(",").size.plus(2),"•")}}<br>
17{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^17$)").split(",").size.plus(2),"•")}}<br>
18{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^18$)").split(",").size.plus(2),"•")}}<br>
19{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^19$)").split(",").size.plus(2),"•")}}<br>
20{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^20$)").split(",").size.plus(2),"•")}}<br>
21{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^21$)").split(",").size.plus(2),"•")}}<br>
22{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^22$)").split(",").size.plus(2),"•")}}<br>
23{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^23$)").split(",").size.plus(2),"•")}}<br>
<br></p>
</div>
</body>

Explanation of what is happening:

• Some HTML formatting around the data to force to a mono-spaced font
• Let's look at one specific line of the histogram output

00{{varEmpty.replace("null",": ").rightPad(lookupIssues.created.convertToTimeZone(lookupIssues.first().reporter.timeZone).format("k").match("(^0$)").split(",").size.plus(2),"•")}}<br>

• Using the dummy varEmpty variable, we replace the contents with a delimiter, ": "
• Right-pad that delimiter with some dots, based upon the count of issues matching our criteria
• To get that count of created-hour issues, we first convert to the Time Zone of the reporter. Lookup Issues is a list, so we must only access one reporter, such as the first() one
• Formatting the created date/time, we grab only the 24-hour time, from 0-23
• Using RegEx, we match on the hour we are interested in for the row, resulting in a CSV string
• Which we then convert to a list using split(",")
• And, we are right-padding a string which already has the ": " delimiter, so we add 2 for the length
• Finally wrapping up with an HTML line break

There are several potential use cases for this one. The key challenge is the 100 issues processing limit; so if your use case fits in that limit I hope this can help you.

Best regards,
Bill

[Bill Sheboy]

Determine if issue is from a next-gen (or classic) project inside a rule

There does not appear to be a built-in way to determine if an issue is from a classic or next-gen project from inside of an automation rule. Projects have a "style" attribute, and this appears to only be available on the project list and in REST API methods at this time. When your automation rules have different behavior based upon classic or next-gen, it can help to determine this within a rule.

Automation rule details:

• Trigger: whatever you need
• Action: send web request to call the REST API Get all projects method.  Or, just get the project for this one issue.
• Action: log the response status for error logging {{webhookResponse.status}}
• Action: create a variable to hold the project keys and styles, calling it varProjects

{{#webhookResponse.body}}{{key}}:{{style}}{{^last}}, {{/}}{{/}}

• Action: log the list of next-gen projects (or switch to classic if you wish)
  • Split the varProjects variable into a list
  • Find any matching next-gen styles with RegEx and match()
  • Remove the string "next-gen" string to create a list

Next-Gen Projects: {{varProjects.split(",").match("(.*next-gen)").replace(":next-gen","")}}

• More actions... If you need to check the issue, compare {{issue.project.key}} for presence in the list

References:

https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/project-getAllProjects

https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/project-getProject

[Lissa Meade]

We have a Celigo integration that takes time logs from Jira and pulls them into NetSuite, but all tickets need epic links. The problem was that our QA team was creating Bugs with a "relates to" link to the ticket it stemmed from, and so we were getting tons of errors since there was no epic link. (We can't use child issues, as you can only have one child issue type in Team Managed project and that is already being used for subtasks.)

I created this automation rule to look for the parent (epic) on a newly linked issue and add it to the Bug, as long as an epic link doesn't already exist. (The action is "Trigger Issue")