Date: Thu, 28 Mar 2024 22:25:30 +0000 (UTC) Message-ID: <45305687.13.1711664730501@ced7fbb13bb2> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_12_614251653.1711664730501" ------=_Part_12_614251653.1711664730501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This is the documentation for JSU for Jira Cloud. If you are using JSU o= n Jira Server/Data Center, see our JSU Server/Data Center documentation.
Goal |
Eliminate repetitive tasks and save time by automatically closing parent= tasks |
---|---|
Scenario |
When your team has closed all of an issue=E2=80=99s subtasks, the parent= issue remains open and someone has to manually move it to DONE. Let=E2=80=99s loo= k at how this common task can be automated with JSU. |
Components |
Linked Transition post funct= ion |
Create a draft of your project workflow. If you're unsure how to get to =
this page, follow the onboarding steps in Edit a Jira Workflow. You can then view your workflow in Text or Di=
agram mode. The steps in this use case represent Diagram mode. If you haven=
't already, switch the workflow viewer to Diagram mode.
We want to close parent issues when their subtasks are done, so we need = to add the rule specifically to when issues transition to the DONE statu= s. Click the arrow that points to this status to show the transition rule o= ptions menu.
We want to add a post function to this transition that runs an automatio=
n after the issue has been transitioned to the target status. Select
Select Add post function to view all available post fun= ctions.
Select the Linked Transition (JSU) post function, and then clic= k Add at the bottom of the page.
We want the parent to automatically close when the last subtask is close=
d, so let's set the Trigger tra=
nsition on all issues related as option to Parent / Subtask > Parent (Is=
sue in Transition must be Sub-Task)
.
Next, we define which transition and in which w=
orkflow we want to transition the parent issue we just select=
ed. We want to keep this rule simple, so we only want this rule to apply to=
issues in our JSU project.
Transition: We se=
lect the workflow that applies to our JSU project and the Done
=
transition. This means any parent issues will be transitioned to
We only want the parent to be transitioned to DONE if ALL of its subtasks are also DONE. To configure this, for All other sibling issues (for example li=
nking to the target with the same link type) must have one of the following=
statuses we set this as Done
.
The remaining fields are optional. For your reference w= e consider how you might want to use these fields. If you're happy = as is, feel free to proceed to Step 9. All of these fields are des= cribed in detail in the Linked Transition= post function page of the Configuration Guide.
Resolution - If you would like to add a resolu= tion to the parent issue after the post function closes it, you can define = which resolution to choose in this field.
Perform as user - In Jira Cloud, all "actions"= both manual and automated, must be performed by a registered Atlassian acc= ount. If you'd like JSU to impersonate another user to run its automation, = you can choose that user here. It's important to note that the impersonated= user must have the right account privileges to perform the action. If you'= re not sure, just leave this field blank. Leaving the field blank means the= automation will be run as the default user, "JSU add-on user" which has el= evated privileges and can perform most functions.
Copy field - If you'd like to add more informa= tion to the parent issue as part of the automation, you can describe what i= nformation you'd like to add here.
Now you're ready to save your new post function. To do this, select
You can now see a summary of all your post functio=
ns applied to this transition. To confirm this new workflow and test it out=
, you need to publish it. At the top of the page, select Publish Dr=
aft. You can choose to save a backup if required before confirming=
.
Now we can go test the post function in action!
Go to an open issue that includes one or more open subtasks.
Transition all of the subtasks to DONE.
Refresh/reload the parent issue. You'll notice that it has now also been=
transitioned to DONE - which means our post function has worked as expe=
cted!
Congratulations! You've just configured your very own automation!
Feel free to continue exploring other use cases for this post function, = such as Close parent Epic when all the issues within the Epic are d= one, and more!
Need more information or help? Get in touch!