Automation - Clonded Issues

[sven deturck]

Hi all,

In our target setup we have Product teams created as a separate project and have an overall Product Project as well which is responsible for E2E testing - Performance testing etc. 

During these E2E testing an issue can pop - up, which will be created as a bug but the actual resolution will be done by any of the product teams responsible for that part of the product.

Our idea would be

- Create the bug as part of the Product project

- Create a clone

- Move this clone to the responsible Product team

Question

- I want to explore the possibility that via automation the status of the original and cloned bug are in sync. Anyone has any experience with this kind of automation setup? Or anyone with a similar setup that set this up in a different manner?

[sven deturck]

Thank you

Let me try this out - seems like a good workaround. But I'll bring up the discussion if we would indeed still need the 2 entities.

Thanks again for the swift reply

KR

Sven

[YY哥]

Hi @sven deturck 

Welcome to our community. 

Firstly, the best practice is keeping a single source of source, which means that we should create only one bug, collaboratively resolved by product project and product team members.

If the process cannot be changed for the time being, then I think we can use 2 automations:
1.Cloning the bug created mannually in product project into the product team project, linking the two bugs (e.g. link type: is blocked)

2.Update the status of product team accroding the status change of product team bug. We need map the statuses in both projects.

Hope this solution helps you.

Thanks,

YY哥

[Stephen Wright _Elabor8_]

Hi @sven deturck 

I agree that having 2 bugs feels unnecessary - it's a duplicate you need to keep updated.

I would either...

• Filter Bugs from the Product Project into each team's backlog - eg. set the "Team" field to the team who will be fixing the Bug, and include these parameters in their board filter
• Create a Story/Task in the Team Project to "fix" the Bug - so it's not a duplicate, it's a task to resolve the issue

---

But, to do what you've asked - you'll need two separate rules:

1. Create the Bug in the Team Project (directly)
2. Sync the Statuses

I've detailed how to do this below.

I've assumed these are Company-managed Projects, and the Rules can be set at a Global level.

---

Rule 1

Prerequesites

You can't move an issue via Automation, so I would have some unique parameter you can refer to to decide which Project the Bug should be in.

For this example, I'm using the Team ID, but it could be a label, component, etc.

You can then use either IF/ELSE Conditions to decide which Project to create the Bug in, or use a Lookup Table. The latter is more efficient, and is used below.

You will need...

• Team IDs...
  • Get these from a Team's URL - eg. 806e8054-6e6e-6f9d-a886-hh5adhiia99c-67
• Project IDs...
  • Get the Project IDs for each team
  • You can get these from Project Settings > Details, ID is in the URL - eg. 10021

• The Team's custom field ID...
  
  • You can get this from Settings > Issues > Custom fields; locate the Team field then view the field's information (via the breadcrumbs (...)) - eg. 10001

---

Rule

The rule will...

• Activate if an issue is created
• Check it's in the right Project, that it's a Bug and has a Team assigned
• Then, create a table to identify all possible Team > Project variations
• And then clone the Bug, setting the Project dynamically

It will look something like this...

• Trigger: Issue created
• Condition: Issue fields condition
  • Field = Project
  • Condition = equals
  • Value = Product Project
• Condition: Issue fields condition
  • Field = Issue Type
  • Condition = equals
  • Value = Bug
• Condition: {{smart values}} condition
  • First value = {{customfield_10001}} - Team field's ID
  • Condition = does not equal
  • Second value = <leave empty>
• Action: Create lookup table
  • Name = projectID
  • Table entries...
    • Row 1
      • Key = 806e8054-6e6e-6f9d-a886-hh5adhiia99c-67
      • Value = 10021
    • Row 2
      • Key = 008f0274-8e8e-8g9f-c0a5-jj7bfiijcbbd-89
      • Value = 10049
    • ...add additional rows, keys and values for each Team ID, and subsequent Project ID
• Action: Clone Issue
  • Project = {{projectID.get(customfield_10001.id)}}
  • Issue Type = Bug
  • Fields...
    • Summary = {{triggerissue.Summary}}
    • Linked Issues = clones, Trigger issue

---

Rule 2

Prequisites

This rule will send the Statuses back from the Team Project to the Product Project.

There's two variations of this rule...

1. Statuses match between the two Projects
2. Statuses do not match

For (2), you will need to map the Statuses within the rule. Similar to Rule 1, this can be done using either IF/ELSE conditions, or a Lookup Table. I'm using a Lookup Table below.

You will need...

• Status IDs for the Team Project(s)....
  • Get each Status' ID, for all possible options
  • You can get these from Settings > Issues > Statuses; hover over the Edit hyperlink to see the ID in the URL - eg. 10086
• Status IDs for the Product Project...
  • Use the same instructions as above

---

Rule 2(1)

This is the simple version, where Statuses match between the two Projects.

This should work...

• Trigger: Issue Transitioned
• Condition: Issue fields condition
  • Field = Project
  • Condition = is one of
  • Value = <all Team Projects>
• Condition: Issue fields condition
  • Field = Issue Type
  • Condition = equals
  • Value = Bug
• Condition: Related issues condition
  • Related issues = Linked issues
  • Link types = clones
  • Condition = Some match specified JQL
  • Matching JQL - project = "Product Project" and issuetype = Bug
• Branch: Related Issues
  • Type = Linked issues
  • Link type = clones
    • Branch-Condition: Issue fields condition
      • Field = Project
      • Condition = equals
      • Value = Product Project
    • Branch-Condition: Issue fields condition
      • Field = Issue Type
      • Condition = equals
      • Value = Bug
    • Branch-Action: Transition issue
      • Destination status = Copy from trigger issue

---

Rule 2(2)

This is the more complex option, where Statuses do not match.

The rule will...

• Activate if an issue is transitioned
• Check it's from one of the Team's Projects
• Set the Status as a variable (for use later in the rule)
• Then, create a table to identify all possible Team Status > Product Status variations
• And then transition the Product Project's Bug dynamically

It will look something like this...

• Trigger: Issue transitioned
• Condition: Issue fields condition
  • Field = Project
  • Condition = is one of
  • Value = <all Team Projects>
• Condition: Issue fields condition
  • Field = Issue Type
  • Condition = equals
  • Value = Bug
• Condition: Related issues condition
  • Related issues = Linked issues
  • Link types = clones
  • Condition = Some match specified JQL
  • Matching JQL - project = "Product Project" and issuetype = Bug
• Action: Create variable
  • Name = teamStatusID
  • Smart value = {{issue.status.id}}
• Action: Create lookup table
  • Name = statusID
  • Table entries...
    • Row 1
      • Key = 10026 - Team Status ID
      • Value = 10082 - mapped Product Status ID
    • Row 2
      • Key = 10025
      • Value = 10083
    • ...add additional rows, keys and values for each Team Status ID > Product Status ID mapping
• Branch: Related Issues
  • Type = Linked issues
  • Link types = clones
    • Branch-Condition: Issue fields condition
      • Field = Project
      • Condition = equals
      • Value = Product Project
    • Branch-Condition: Issue fields condition
      • Field = Issue Type
      • Condition = equals
      • Value = Bug
    • Branch-Action: Transition issue
      • Destination status = {{statusID.get(teamStatusID)}}

---

Notes

• You can see more about how Lookup Tables work on this help page
• I've kept the multiple conditions separate to help visualise the rule - you could combine these to make the rule more succinct for conditions outside a Branch. To do this, use an "IF or ELSE" condition, and then add the sub-conditions in there together.
• You could still use the Rules to create and align a Task in the Team's Project, if you decide duplicating the Bug isn't ideal.
• You could narrow the scope of the rules, to limit when they execute - you can do this from...
  • Rule details > Scope
  • Change "Global" to "Multiple projects"
  • Enter all relevant Projects (Teams and Product)

---

There's a lot to digest here!

Let us know what you think, and if you have any questions we'd be happy to help :)

Ste

[sven deturck]

Hi Stephen,

Thanks for the elaborate answer - it seems to me that the first option of having it in only one place is the most efficient one to go with, so I'll open up that discussion again.

Meanwhile I'll explore how to set up the automation with your description it is very detailed and I should be able to set it up with this.

Thanks again for your thorough answer

Kind regards

Sven

[Stephen Wright _Elabor8_]

No worries, let us know what you go with!

And if this answer did help, could you accept it? That helps others who find this question in future know it could help them too :)

Ste