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

Change Workflow Status upon a Child Issue being present

Adam Rosenbaum_0ce6b3

I have a S/W project with a Kanban board with 3 columns (Not Yet Started, Epic In Progress, Done). The only Issue type here is Epic. An Epic will be created on this board, each time a new issue is created in another service project and will be set to Not Yet Started status. Other teams will link their tasks to this Epic. Once the first task is linked the the status of the Epic will move to Epic in Progress. Below is a screenshot of the rule that I created, but it doesn't seem to be working. Screenshot 2023-11-30 at 2.09.30 PM.png

Accepted answers

All comments

Ste Wright

Hi @Adam Rosenbaum

I assume when you state "link their Tasks" you mean set a child's parent as the Epic?

If yes, the Trigger Issue Linked won't work, as this is for sibling relationships (eg. blocks, clones), rather than a parent/child relationship.

---

Instead a rule like this should work (which is triggered from the child Issue):

Trigger: Field Value Changed
- Field to Monitor = Parent
Condition: Issue Fields Condition
- Field = Issue Type
- Condition = equals
- Value = Task
Condition: Related Issues Condition
- Related Issues = Parent
- Condition = Exists
Branch: Related Issues
- Type = Parent
  - Branch-Condition: Issue Fields Condition
    - Field = Status
    - Condition = equals
    - Value = Not Yet Started
  - Branch-Action: Transition Issue
    - Destination = Epic In Progress

---

Let us know if this works!

Ste

Adam Rosenbaum_0ce6b3

Screenshot 2023-11-30 at 8.12.53 PM.png does this look correct? And also, can you explain to me what is actually happening here so I can learn from this as well. Thanks You

Adam Rosenbaum_0ce6b3

Screenshot 2023-11-30 at 8.12.53 PM.png

Sorry I think I may have replied in the wrong place. Does this look correct and can you explain this rule in more detail as i would like to make this a learning experience. Are you suggesting that the parent in the issue linking to the Epic which is the child?

Adam Rosenbaum_0ce6b3

Screenshot 2023-11-30 at 10.19.32 PM.png

actually did not work but also note that I had to add task as a Issue Type

When I link a task to my epic via the epic link field, and I see that task show up in my epic under Child Issues, is that the Parent field I am seeing that task in?

So if the parent change field changes and the issue type is task and a value exists in parent then move the status. Should it be does not exist?

Ste Wright

Hi @Adam Rosenbaum

Yes, that's the Parent field.

Atlassian is deprecating the "Epic Link" field soon - see this article - replacing it with Parent. So using this option in the rule is more future-proofed.

---

The rule works as follows...

When an issue's parent field (eg. Epic Link) is modified, trigger the rule
If...
- The Issue Type is Task
- And a Parent is present
Then locate the task's parent (i.e the Epic)
And if the Epic isn't already in "Epic In Progress", transition it

---

A few notes...

I assumed the Issue Type needed to be "Task" from your original question. If this is not the case, and it's just any child of an Epic, you could add more Issue Types here (eg. Story, Bug, etc).
If an Epic is in "Not Started" the assumption is it has no children. So once one is added, the rule transitions it across.

Ste

Adam Rosenbaum_0ce6b3

So I'm writing this automation in the project where the task is coming from? And I'm making it a global policy?

Ste Wright

Hi @Adam Rosenbaum

That depends if the issues are all in one Project, or if they broach across multiple.

If it's 2+ - set the rule to be...

Global: If this should be the set rule for all Projects
Multiple Projects: If it's more than 1 Project, but is not required for all Projects

Ste

Adam Rosenbaum_0ce6b3

Thank you for the explanation. It looks as if this rule should be created in the project where the issue is coming from. We have many teams each with their own projects that will be linking their issues to the Epic. It would be much less complicated to write this rule in the project where the epic lives.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management