Simplify this automation rule: Clone issue that does not already exist in project
Asked by cho:

Hi community,

I feel like I'm complicating something that should be simple. I'm a Jira newbie, so please bear with me. Thanks in advance for your help.

I'm looking to clone a ticket based on a few restrictions. However, my (Global) automation rule (in our Jira Cloud server) is ballooning and I'm also stuck on how to get "clone if not exist in project" working.

In plain English, the automation should go like this:

* **All** issues **EXCEPT** issues in project ZZZ
* **Assigned to** users in GGG group
* **AND** issue does not already exist in project ZZZ (i.e. there isn't an issue with a similar summary in ZZZ)  
  * **if** issue type doesn't exist in project ZZZ --\> clone issue + link issue + set issue type to \[an existing issue type in project ZZZ\]
  * **if** reporter is not active --\> set reporter to assignee
* **Clone** the issue to project ZZZ with all the same properties as the original issue
* **Link** the existing issue to the newly-cloned issue

Here is what I currently have set up, that is working without the duplication check:

```
[Trigger] When: Issue assigned
[User condition] Assignee is in GGG
[Issue fields condition] Project is not one of: ZZZ
  [If] Issue Type is not one of: (Issue Types in ZZZ)
    [---Then] Clone issue in ZZZ, set to an Issue Type in ZZZ, link issue
  [Else-if] Reporter is not in: GGG
    [---Then] Clone issue in ZZZ, set Reporter to Assignee, link issue
  [Else-if, all match] Issue Type is not one of (Issue Types in ZZZ) AND Reporter is not in GGG
    [---Then] Clone issue in ZZZ, set to an Issue Type in ZZZ, set Reporter to Assignee, link issue
  [Else] Clone issue in ZZZ (keep all properties)
```

I find the automation is "ballooning", because what if BOTH the issue type doesn't exist and the reporter is not active? I need an "if" block for each individual case, but then I need an extra "else-if" block for when both of these cases are met at the same time.

I actually have a third "if" case: if the issue's status/workflow exists in ZZZ, then clone it; otherwise, clone to Backlog. But the amount of if-blocks will exponentially increase to match each case with each other..!? I was going to list out all the cases as an example (if 1 and 2 but not 3; if 1 and 3 but not 2...), but I feel incredibly dumb. I've given up on the if-blocks for the time being.

\[EDIT: I thought I got the if-blocks working, but they don't! If I have an issue where both the assignee is deactivated and the issue type doesn't exist, then the issue doesn't get cloned properly. It works fine if the issue matches 1 of the cases, but it breaks when both cases are met...? I'll have to keep investigating...\]

My main problem is that I can't seem to get the issue duplication check working. I know I should be using the JQL query **project = "ZZZ" AND s** **ummary \~ "\\"{{issue.summary}}\\""** (or something along those lines anyway), but I started to get confused when I was testing this JQL in the search bar.

We don't have ScriptRunner installed. I wanted to see if we can get away without needing to install it, but if it makes life easier, then we can install it.

Please save me. I've been fighting with this automation rule for the day and I feel belittled.


Answers:
author: Bill Sheboy
body: Hi [@cho](/t5/user/viewprofilepage/user-id/5417853) -- Welcome to the Atlassian Community!

I am curious: what problem are you trying to solve by cloning all of those issues? That is, why do this?

Regarding your questions, and without seeing your actual rule image and audit log details, my recommendations would be:

* verbally explain the scenario to another team member; that will help confirm your own understanding of the need, and identify any alternative approaches
* pause, and write down all of the testing scenarios / permutations for your need
* disable your current rule
* create a new rule
  * adding the simplest path through it first,
  * test it,
  * when successful, incrementally add the next scenario,
  * repeat until done
* when evaluating your rule conditions, identify what is common and pull those simple conditions up higher in the rule, before any if / else conditions
* test thoroughly and document and decisions

Kind regards,  
Bill

comments: author: cho
body: Hi Bill, thanks for asking! Perhaps this can be done differently from the get-go.

Users from group GGG work in multiple projects. Team managers want to be able to see GGG users' workload in ++one++ place -- project ZZZ, so duplicating issues to ZZZ was the solution\*.

Sometimes GGG users forget to clone the issues, which distorts their actual workload. If this process can be automated, then it saves them a step.

\*Someone did try using a dashboard view, but it had limitations (not sure what). Creating a filter also wasn't an acceptable solution. I don't know if there's a better way to do this, but creating this automation rule seemed easy.

Thank you for the recommendations! I'll give my think process a restart. This automation rule is also not urgent, since they've been manually cloning tickets themselves for awhile now, so I have plenty of time to get this working.


author: Bill Sheboy
body: Thanks; that helps clarify things!

This scenario is normally solved by creating a combined filter for the projects, saving it, and creating a new Kanban board. This board is treated as read-only to prevent impacting the delivery teams' work. Clone creates synchronization and other problems, which are not easily solved...and so lead to confusion and errors.

For example:

* Create a filter like this: project IN (A, B, C) ORDER BY Rank ASC
* Save and name that filter
* Create a Kanban board from the filter
* From the board settings, adjust the columns and status mapping as needed

You seemed to indicate "a filter also wasn't an acceptable solution." What were the reasons why that was not acceptable? Perhaps the new board was not yet tried to visualize the items.


author: cho
body: Ahh thank you Bill!

I had another discussion with our PM. He'd already tried filters + Kanban board, but 1) they want to see the amount of workload of each user (in group GGG) in a sprint. Each project board has varying sprint values, and they rotate every 2 weeks too.

Honestly, I'm not too sure, but I'll try to set up this automation rule as best as possible.

It just looks terrible with all the If-cases, and I was wondering if there was a better way to do it. I won't accept an answer yet -- maybe someone else may have a better idea. Otherwise I can accept your reply just to close this question.

Thank you so much for your time!! I appreciate it.  
Carol


author: Bill Sheboy
body: Hi [@cho](/t5/user/viewprofilepage/user-id/5417853)

Just checking if this answered your question. If so, please mark this one as "answered" to help others find solutions faster. If not, provide any additional information to help the community provide suggestions.

Thanks!


Tags: clone

duplicate