nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automatically Link Tickets Generated from Scheduler

Dan Schetley

Hello,

I'm hoping we're just over thinking this, and there's an easy answer, but we currently have 60+ JIRA stories in a Kanban project created by the Scheduler on the first of each month. What we're trying to do is migrate those stories to the Scheduler in a JIRA Work Management board and automatically link them through an Automation since the tickets have dependencies on each other (can be one to one, or one to many dependencies). This way the progression will show up in the Timeline tab of JIRA Work Management. Below are examples of the ticket structure:

- Ticket A is dependent on B being completed and A should be blocked by B

- Ticket D is dependent on B and C being completed and D should be blocked by B and C

The goal is to try to avoid someone needing to manually go in and link the tickets in the JIRA Work Management board.

Accepted answers

All comments

Bill Sheboy

Hi @Dan Schetley

Regardless of the way the issues are created, an automation rule would need guidance for the linking.

If you are creating these with a scheduled trigger automation rule, the linking could probably occur there, either through absolute (e.g., a specific key and link type) or relative linking (e.g., link to the last issue created in the rule).

Kind regards,
Bill

Joe Tobey

@Bill Sheboy I was working to help @Dan Schetley with this and I was getting stuck on the relative linking related to the "last issue created". It kept trying to reference itself. For example:

Automation Creates Issue1 then Issue2. When I use the relative linking, it sees Issue2 as the "Last Issue Created" and errors out as it cannot reference itself. any thoughts for getting around that?

Bill Sheboy

Hi @Joe Tobey

There are a couple of solutions for that...

First, as issues are created in the main execution path of the rule, two smart values are available: {{createdIssue}} and {{createdIssues}} (note the plural). With the second one any of the previously created issues could be referenced using the get() function in the list, with {{createdIssues.get(n)}} where n is a 0-based index for the issues. And so the first one is 0, and the key is {{createdIssues.get(0).key}}

That method breaks down if the issues are created either inside of an if/else structure or a branch, due to scoping issues. (There is sometimes a work-around for that, using the method below.)

The second method is to save the {{createdIssue.key}} with the Create Variable action after the issue is created. This method is often used when cloning a tree of issues, like the epic and its children.

Kind regards,
Bill

Dan Schetley

Hi @Bill Sheboy ,

Thanks for the quick responses. Would it be possible to send an example automation for my example above:

Ticket D is dependent on B and C being completed and D should be blocked by B and C

I think if we could get that then we can build upon it from there.

Thanks,

Dan

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation