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.

[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

[Ste Wright]

Hi @Vineet.Kotian 

You might need 3 rules overall...

1. Copy the Fix Versions for existing Sub-tasks (one-off rule)
2. Copy the Fix Versions during Sub-task creation
3. 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

[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

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

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

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

[Rick Dorgan]

Correct, it's the one I am showing above. Which based on Rule 2 above, I thought would result in a subtask inheriting the parent fix version at the time the subtask was created.

Interestingly enough, the logs aren't showing any attempts at execution. This is new territory for me, so feel free to dumb things down if I'm not answering your questions well :)

[Bill Sheboy]

No worries; we are all learning all of the time!

Without re-reading all of the prior thread posts, I'll ask: who (or what) is creating the subtask?

When a person creates an issue, that rule will certainly trigger.  If it is not, that needs to be investigated further.

But when another rule creates an issue, by default rules do not trigger.  This is to prevent accidental rule execution, looping, and a "run away" execution scenario.

When the rules we create are intentionally meant to execute others, the option "Allow Rule Trigger" may be enabled in the rule.

So please outline for me: for the rules (1-3) are the actions of any of these rules intended to trigger other rules?

[Rick Dorgan]

I'm manually creating the subtask myself within an existing issue.

Rule 1: I'm not using this rule

Rule 2: The creation of a subtask is triggered by me clicking the create subtask button

Rule 3: This is working as intended. If I manually update the Fix Version of the parent ticket, the subtask inherits it.

[Bill Sheboy]

I cannot think of a reason that Rule 2 with the Issue Created would not trigger if you are manually creating the subtask in the same project as where the rule is defined.

Let's confirm some context:

• What version of Jira are you using: Cloud, Server, or Data Center?
• What type of project is this: software, business, something else?
• If a software project, what type is it: Company-managed or Team-managed?
• How are you creating the subtask: from the issue view's Create Subtask button, from the "." action menu, from somewhere else?

[Rick Dorgan]

Yep, it's definitely in the same project. Rule 3 is showing up as in the same project and rewrites the fix version for subtasks in the same story that I'm working in for Rule 2. Strange. Answers to your questions:

• What version of Jira are you using: Cloud, Server, or Data Center?
  • Atlassian Jira Project Management Software (v9.12.1#9120001-sha1:8c0c8f7:jiradc-0) I've been told Server.
• What type of project is this: software, business, something else?
  • I believe software (which I think makes sense since we're a software company)
• If a software project, what type is it: Company-managed or Team-managed?
  • I believe company managed. I seem to have advanced planning access.
• How are you creating the subtask: from the issue view's Create Subtask button, from the "." action menu, from somewhere else?
  • I've tried making a subtask from the More -> Create Subtask menu, and also by clicking the + symbol within the Subtask section of the ticket. Neither result in an updated fix version.

[Rick Dorgan]

Maybe this sheds some light on my challenge...none of the fields under Details (screenshot) are editable within the sub-task. This is why I ended up looking into automation in the first place. I read in a different thread that updating the Workflow would solve this issue, but I have read-only access to my Workflow (second screenshot) so I went the automation route.

FYI, I've tried other automation rules (trying to have my sub-tasks inherit parent summary using smart values) without success. Is it possible this is a privilege issue? Though the success of Rule 3 would argue against this....

[Bill Sheboy]

Thanks for that information, although the puzzling part is still why the rule does not trigger.

While in the project where the rule is defined, if you create a story (not a subtask), does the rule trigger?

If not, please show an image of the Rule Details section, as that may indicate why the rule does not start.

[Rick Dorgan]

I tried what you asked. Created a story within the same project as the rule, and viewed the log. No rules were triggered. Rule Details screenshot is attached. However, wouldn't I need to create a subtask in an already created story for the rule to trigger?

[Bill Sheboy]

No: the rule should trigger when any issue is created, and the conditions are what limit which actions are performed.

This new information may indicate a potential problem with either permissions or the rule's internals leading to a broken rule.  We can check each with this:

Permissions...I see you have changed the Rule Actor away from the default value of Automation for Jira.  Try switching that back as the default user has permissions to do more than most people-users.

Broken rule...Rules can get "glitched" from too many edits / publish cycles, breaking something internally.  I do not know why this occurs, but the ways to check it are:

• Disable the rule, wait a minute, re-enable it, and then re-test.  If that does not help...
• Disable your current rule, and re-create it from scratch.

[Rick Dorgan]

It looks like I'm being added as the rule actor by default (I created a new rule to confirm). And the user 'Automation' doesn't exist in my drop-down. I do see a user called 'svc cloud-group-automation'. I tried using them as the Rule Actor, and no luck. I don't have access to search users and confirm if this svc cloud-group-automation user is part of another team or not, but tried anyways.

I also tried disabling, re-enabling the rule. No change with retesting. I also tried disabling the rule, and recreating it. No luck with that either.

Rule details and audit logs attached. Thank you for continuing to help with this!

[Bill Sheboy]

I'm using Jira Cloud, and the default actor is always Automation for Jira.  That appears to be different for Jira Server, and so I recommend leaving it as the default...whatever that value is.

It makes no sense to me that the rule would not trigger at all if you are creating the issues in the same project as where the rule exists.

At this point, I am out of suggestions, other than to work with your site admin to submit a support ticket to Atlassian: https://support.atlassian.com/contact/#/  Once you hear back from them please post what you learn.

[Ste Wright]

Hi @Rick Dorgan 

Other rules do trigger in this Project?

And you (or the rule actor) definitely has permission to edit issues?

Ste

[Rick Dorgan]

@Ste Wright- that is correct. Attached is a screenshot of a rule that works successfully. I can seem to make things happen for the trigger Field Value Changed, or Issue Transitioned, but nothing seems to work when I use the trigger Issue Created.

I am the defined rule actor, and manually create/edit tickets all the time. My defined role is showing up as Administrators and Resolvers (screenshot attached as well). I was planning to submit a support ticket tomorrow when I'm back at work as Bill suggested, but am happy to continue troubleshooting if you can think of anything. 

[Rick Dorgan]

@Bill Sheboy- I reached out to my site admin this morning, and while waiting to hear back explored the URL you provided to submit a ticket.  It looks like I need a cloud product to post there. From what I've been told, our team's board is fully separated from the cloud. The URL is https://jira.COMPANY-NAME.com. Does this change anything?

[Bill Sheboy]

Please follow up with your site admin on how to submit a support ticket for your product.  My understanding is Atlassian Support for Jira Server ends on 15 Feb 2024; after that only Cloud and Data Center will have support.

To learn more about that support change, please look here: https://community.atlassian.com/t5/Atlassian-Migration-Program/45-days-til-Server-end-of-support-Your-top-questions-answered-Q/ba-p/2573942

[Ste Wright]

Hi @Rick Dorgan 

Have you tried simply recreating and/or duplicating the rule, see if this works?

You could also try reindexing the platform.

Ste

[Rick Dorgan]

Hey @Ste Wright - I did try recreating the rule, and no change. I'll share with my site admin your suggestion to re index the platform. I'm still waiting to hear back from them, but a ticket was opened with my team earlier this week.

[Rick Dorgan]

I found this article and tried out the manual trigger, which worked as expected...but adding in "3 re-fetch issue" data actions didn't make a difference. Still waiting for assistance from my site admin, so continuing to troubleshoot for now :)

[Ashish Sathyan]

@Vineet.Kotian @Bill Sheboy @Trudy 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.