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

Jira Automation Rule to apply Fix version to subtasks

Vineet.Kotian

I am looking to create a Jira Automation rule which applies fix version to all sub-tasks based on the fix version applied to its parent story.

1. I want to run this rule on already created subtasks

2. I want to create a new rule which will run every time a story is created and assigned a fix version.

Accepted answers

All comments

Ste Wright

Hi @Vineet.Kotian

You might need 3 rules overall...

Copy the Fix Versions for existing Sub-tasks (one-off rule)
Copy the Fix Versions during Sub-task creation
Copy the Fix Versions if a Story's versions change

^ This should cover your need I believe.

---

Rule 1

For the one-off rule, you can use a Scheduled Trigger, which allows you to run a rule manually.

The rule will look like this:

Trigger: Scheduled
- Run Rule Every = 1 Weeks - the value here is not relevant
- Run a JQL search... = TRUE (check the box)
- JQL - issuetype = Sub-task
- Only include issues that have changed = FALSE (uncheck the box)
Action: Edit Issue
- Field = Fix Versions
  - COPY - access this option from the breadcrumbs (3-dots icon)
    - Issue to copy value from = Parent Issue
    - Field to copy value from = Fix Versions

Once you've created and published the rule, press the blue Run Rule button to activate it immediately. Once it has successfully completed, you can then disable and/or delete this rule.

---

Rule 2

The rule will look like this:

Trigger: Issue Created
Condition: Issue Fields Condition
- Field = Issue Type
- Condition = equals
- Value = Sub-task
Action: Edit Issue
- Field = Fix Versions
  - COPY
    - Issue to copy value from = Parent Issue
    - Field to copy value from = Fix Versions

---

Rule 3

This rule is a little different, as the trigger is against the parent, but the action is against the sub-task(s). This is achieved using a Branch...

Trigger: Field Value Changed
- Field = Fix Versions
- Change Type = Any changes to the field value
Condition: Related Issues Condition
- Related Issues = Sub-tasks
- Condition = Are Present
Branch: Related Issues
- Type = Sub-tasks
  - Branch-Action: Edit Issue
    - Field = Fix Versions
      - COPY
        Issue to copy value from = Parent Issue
        
        Field to copy value from = Fix Versions

---

Let us know if these all work for you

Ste

Mark Segall

Hi @Vineet.Kotian

You'll need a couple rules for this:

Parent Issue Fix Version has been set/changed

TRIGGER: Field Value Changed (Fix Versions)
BRANCH: Sub-Tasks
- ACTION: Edit Issue (Fix Versions)
  - Select the ellipses on the right >> Copy
  - Copy from Parent Issue

New Sub-Task Created

TRIGGER: Issue Created
CONDITION: Issue Type = Sub-Task
ACTION: Edit Issue (Fix Versions)
- Select the ellipses on the right >> Copy
- Copy from Parent Issue

One Time Update of all Sub-Tasks

This rule can be disabled after it has been executed once and the other two rules are live

TRIGGER: Schedule
- issueType = Sub-Task
ACTION: Edit Issue (Fix Versions)
- Select the ellipses on the right >> Copy
- Copy from Parent Issue

Bill Sheboy

Hi @Vineet.Kotian

Yes, and...to the other answers provided.

Synchronization rules can be challenging when you want to cover *all* possible scenarios. Please consider which ones you want versus need, as that will determine how many rules you need and what they do. For example:

sub-task added to a parent issue
sub-task removed from a parent issue (i.e., moved)
version edited in a sub-task, making it out of synch with the parent
version changed in a parent issue
- special case of above: version cleared in a parent issue
version deleted from the project by some mechanism other than the UI
update existing subtasks to synch to parent, based on criteria above
- question: do you want to do this for closed issues or only for ones not yet completed?
and so forth...

Please consider: what is the problem you are trying to solve by doing this? For example, if this is to solve a reporting need there may be another approach than synchronizing the fields.

Kind regards,
Bill

Ashish Sathyan

@Vineet.Kotian @Bill Sheboy @Trudy P Claspill The above rule did work. However, we have a problem wherein. If I remove a fix version from a story and replace it with a new one and then repeat the same process again. The old and the new fix version appears under the fix version field. How do I resolve this?

Bill Sheboy

Hi @Ashish Sathyan

I recommend you create a new question, and perhaps link back to this thread. That will ensure greater visibility to the community to help.

When you create your question, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Kind regards,
Bill

Ashish Sathyan

@Bill Sheboy How Do I delete this answer? I am not seeing an option on this page.

Bill Sheboy

I believe only the admins and community leaders can do that, so you can ignore this one and focus on your new question.

Rick Dorgan

I'm focusing on Rule 2 and 3 posted above by @Ste Wright , but am running into trouble. Rule 3 works great. If I update the parent fix version, the subtask fix version updates as well.

Rule 2 is where I run into problems If I create a new subtask, the fix version is defined as None. I tried creating a new story, followed by a new subtask, and it still doesn't work. Any ideas? Here's a screenshot of what I have in place for Rule 2.

Screenshot 2024-01-11 at 2.19.31 PM.png

Bill Sheboy

Hi @Rick Dorgan -- Welcome to the Atlassian Community!

The cause of this symptom could be a timing problem...

The Issue Created trigger can fire so quickly that the issue data is not fully available to the rule yet. For your scenario, that could include the parent data being missing, and so the edit does not work as expected.

The work-around for this is to always add the Re-fetch Issue action immediately after the Issue Created trigger. This will slow the rule down, reloading the data before proceeding with the other steps. Please try that to see the impact.

Kind regards,
Bill

Rick Dorgan

Thanks, @Bill Sheboy . I tried adding that in and still no luck. Let me know if this looks correct, or if there's anything else I can try.

Screenshot 2024-01-11 at 4.19.56 PM.png

Bill Sheboy

Which rule are you expecting to set / update the Fix Version? Is it the one you are showing?

For the rule you expect to set the field, please post an image of the audit log details showing the rule execution which did not work as expected.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud