Link newly created Task to existing Task

[Kathryn Swearingen]

Wondering how to link a newly created Task issue to an existing Task issue. 

Real high level workflow for our group:

We update websites. We assign a Task issue to the developer on a per-web page-basis who works the scope and then closes their ticket and assigns the QA Task to QA (this is our way of working; can't change this). One requirement of the developer is to edit a custom field in the Task called "Edited Nodes" so that when it comes time to move from one environment (Staging) to the next environment (Preview) we know which files to move, which we gather from all of the Tasks that were assigned to the developer.

It would be great if at the beginning of a project I could proactively create the Move to Preview Task so that it exists when any newly created developer Task is created and have those newly created dev Tasks link to the project's Move to Preview ticket. 

If it helps, these tickets are created through Jira automation rules (mostly manually triggered) and I've set those rules up to use specific Labels, so for example the Move to Preview Task has its own specific label; the developer Task has its own specific label, etc. 

So... is there a way to create a ticket at the beginning of a project and have any future tickets that are specific to the developer linked ("relates to") to the ticket that was created at the beginning of the project? Note that all of the tickets associated with a project link to the same Epic and I also use Fix Version, so all tickets in the scope of the project would link to the same Fix Version (and Epic). I will also probably want to link any Bug tickets with the same Epic and/or Fix Version to the Move to Preview ticket in case Edited Nodes are listed there, too.

[Bill Sheboy]

Hi @Kathryn Swearingen 

Lots of moving parts in your solution...please consider: what would be the triggering event/conditions to form that issue link for the future issues (i.e. tickets)?

As you have already created other automation rules to help, if you can identify the trigger and conditions for your workflow you can create a rule to perform the linking.  For example, if the Epic and/or Fix Version is the driver, creation of either could be used to create all the related and necessary issues, with linkages.

Kind regards,
Bill

[Kathryn Swearingen]

We create the Fix Version first then the Epic. Then, using a manual trigger automation rule, we create a User Story per web page that has to be updated, and then we create the developer Task per User Story. Those are also manual triggers. We don't have those automatically created because how would Jira know how many User Stories to create since it doesn't know how many pages we're editing in the release. 

So my thought is to make the Move to Preview task as early in the project as possible so that any future developer tasks that we have to create can automatically link to the move to preview task. I was thinking that the use of Labels might help... kind of like "a new Task with a label specific to the developer was just created so automatically link this new task to an existing ticket that has the same Epic and Fix Version that has a label for moving to preview" -- I just can't figure out how to translate that to make the rule. 

[Bill Sheboy]

Thanks for that information, Kathryn.

Have you considered creating the first developer task at the same time as the initial story, in the same rule?

Next, from where do you create additional developer tasks?  For example, do you run the manual rule from the same initial story for the web page requirement?

[Kathryn Swearingen]

Hi,

Yes! We considered that. 

Here's the rule that creates the DEV task. 

Once the Epic is created, we use Jira automation for a rule that manually triggers the creation of a User Story (run from the Epic). Once the User Story is created (because we need one User Story per one web page) we run a manual trigger rule that then creates the developer, QA and UAT Tasks (we need these per our group's ways of working), and those newly created Tasks are automatically linked to the User Story

The rule looks like this: 

So... we were approaching this one of two ways:

EITHER proactively create the Move to Preview ticket at the very beginning of the project so that any issues that get created that are assigned to DEV would automatically link to the Move to Preview ticket

OR wait until we're done with all development, then create the Move to Preview issue and upon issue creation go find the relevant dev tickets and link the move ticket to those dev tickets.

Either way, we can't figure out the automation logic to achieve the desired linkage. I thought use of Labels would help (ex: all DEV tickets have a dev label and all Move to Preview tickets have a Move to Preview label) and all tickets associated with a release will have the same Epic and same Fix Version (Release). 

[Kathryn Swearingen]

Writing it out in English it's like we want to do this (if we wait to create the move to preview ticket after all dev tickets):

when a new issue is created with label "move to preview" and an epic and fix version then go find all other issues in the same epic and same fix version that have a label "dev" and link the newly created move to preview ticket to the dev tickets.

Not sure if this involves complex branching, if/then statements and jquery/smart values

[Bill Sheboy]

Thanks for those details and your summary.  Perhaps this rule would implement your idea of waiting until the "Move to Preview" issue is created:

• trigger: issue created
• action: re-fetch (this will slow down the rule and reload the data, preventing timing problems from the trigger firing too quickly)
• condition: ??? however you determine this is a "Move to Preview" item; i.e. label, issue type, summary, etc.
• branch on JQL: find an DEV tickets related to the trigger issue.  I recommend creating and testing this JQL first to confirm it works as you expect
  • action: link to trigger issue.

Of note: if your "Move to Preview" issue can be created by another rule (not just manually), you will need to enable this new rule's option for "Allow Rule Trigger" so it can be fired by other rules creating the issue.

[Kathryn Swearingen]

Thank you for this. I completely missed the re-fetch option, and now that totally makes sense. 

Since I don't have a development background, I do struggle with writing JQL (I rely heavily on Google searches). How do I write JQL that translates from "if the Fix Version of this newly created DEV ticket is the same as the Fix Version of this re-fetched Move To Preview ticket then we're good and I'll proceed with my actions"  (sorry -- I don't know how else to express this). I did a Google search and found something like this, based on JQL search extensions:

issue in fieldsHaveSameValue("Fix Version", "Epic Name")

but when I try to validate, it says invalid JQL. Screenshot shows my rule and the invalid JQL. Any help with the JQL would be very appreciated. 

[Bill Sheboy]

First thing, you may want to try this free training from Atlassian on using JQL to answer questions.  https://university.atlassian.com/student/path/849533-gain-project-insights-through-jql  Lots of our non-development background people find it helpful.

Next, you may not need JQL extensions/addons for your rule, so let's figure out what would work...I recommend trying your JQL with example issues in the Advanced Issue Search to validate it before using it in a rule.  For example, substituting in a key and parent epic for what a trigger issue would supply.

Your initial JQL to find the Dev issues related to the trigger issue could be this for the branch.  Please substitute in your myProjectName.

project = myProjectName AND issueType = Task AND fixVersion = {{triggerIssue.fixVersion}} AND parent = {{triggerIssue.parent}} AND labels IN ("DEV")

[Kathryn Swearingen]

Thank you so much for your replies, I really appreciate it. Using your JQL, I was able to make the solution. Instead of it being automatic, it's a manual trigger, which I'm fine with. For me, fixVersion = {{triggerIssue.fixVersion}} wouldn't validate (I tried first in Filters -- Advance Issue Search)

Here's the rule:

1. Manual Trigger

2. JQL (with generic values; this will grab every developer ticket and every QA bug and UAT bug where edited nodes may be listed by the developer when fixing the issue)

project = ProjectName AND issuetype in (Bug, Task) AND fixVersion = "domain.com 1.0" AND labels IN ("DEV", "QA-BUG", "UAT-ISSUE")

[note, the JQL validates when setting up the rule; it's great to have that check available]

3. Then link to trigger issue. 

So, I create the Move to Preview issue first like I normally do, then from in the issue I run automation and choose the rule and it runs perfectly. Before running the rule I just have to edit the fixVersion value for the one I want to search; everything else stays the same.

Our team's next goal is figure out a rule that will fetch the content from within our Edited Nodes [paragraph] field in all qualifying issues and put them in the Edited Nodes field of the Move to Preview ticket. That's our Holy Grail of Jira automation! 

[Bill Sheboy]

I am glad to learn you have a rule that works for you.  As you note, JQL with smart values cannot be validated when creating the rule...And that is why you could test manually with Advanced Issue Search first (or by typing in a value as you have done), and then substituting in the smart value.

Regarding your next goal, accumulating text values within a rule branch/loop may not easily work due to asynchronous processing of each item.  The workaround for that would be to use JQL to gather the issues with a Lookup Issues action, and then concatenate the results.  For example, this would do so for the description field, adding a comma between entries:

{{#lookupIssues}}{{description}}{{^last}}, {{/}}{{/}}

[Kathryn Swearingen]

We've been using Advance issue search to validate. One thing we can't seem to use/validate is: "fixVersion = {{triggerIssue.fixVersion}}"

Any idea why? Just won't work for us. We have to provide a specific Fix Version name instead of finding the same fix version as the trigger issue. 

Thanks!

[Bill Sheboy]

Hmmm...That field is a list so perhaps try this:

fixVersion IN ( {{triggerIssue.fixVersion}} )

I believe that will default to checking the id value and change to a list when the trigger issue has multiple versions assigned.

[Kathryn Swearingen]

I tried fixVersion IN ( {{triggerIssue.fixVersion}} )  but that still didn't work. 

So as of right now I'm stuck at finding the JQL that finds all other tickets with the same Fix Version. 

[Bill Sheboy]

Oops and sorry as I had a typo.  The smart value is plural and the field is singular...even though they are both lists.  Please try this in your branch:

fixVersion IN ( {{triggerIssue.fixVersions}} )

[Kathryn Swearingen]

Yay! You did it! THIS WORKED! I now have the rule to link all dev-related tickets to a single ticket. 

Thank you so much for your help. You're my Jira Hero! 

now on to that Holy Grail ticket....

[Bill Sheboy]

Awesome; I am glad to learn that helped!