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; } } }

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.

Accepted answers

All comments

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).

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud