Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Automation rule - cloning to another project making two clones?

Edited

Set up a very straightforward automation rule that clones an issue to another project. When that rule executes, it creates the clone in the opposing project perfectly. However, it also creates a clone in the same project as well. There is no evidence in the Audit log the second clone is created at all, which leads me to believe this is a bug. Anyone else encounter this?

2 answers

1 accepted

2 votes
Answer accepted

Are the source and destination projects Team Managed or Company Managed?

Can you show us your rule, please?

Thanks for the quick response! Both are Company Managed. There are one of these rules for each project, keying off the "Clone Status" variable. Project names are Starling and Vision.
rule.png

Is the Clone Status field a custom field? (I don't see it in my own JIRA instance.)

How is that field getting changed to the value "To Clone"?

In the step "Then: Edit Issue Fields: Clone Status", to what value are you setting the Clone Status field?

Yes, Clone Status is a custom field that is set manually when a clone is needed from "Possible Clone" (default value) to "To Clone" during review of the ticket.

The "Then: Edit Issue Fields: Clone Status" step changes the current ticket from "To Clone" to "Has Clone"
rule2.png

When the cloned issue is created in the other project, what is the initial value for the Clone Status field for that new issue?

When you end up with a clone of the issue in the same project, what does it have as a link for "Clones"? (I assume this process is resulting in the creation of the "clones/is cloned by" link between the source and new issue.)

In the "And: Clone issue into" step, I set the clones "Clone Status" field = Has Clone

The clone in the same project has just the original ticket under the Linked issues: clones section.

NOTE: by turning on only this one rule, the problem went away. Each project has a sister rule, and it is only when they are both enabled that this problem occurs. That must mean the other rule kicks in when the clone is modified at the end. What I don't understand is how it gets to the "To Clone" state, since that is not the default and I am not setting it to that status.

Hi @Gene LaMantia 

This type of rule pattern has racetrack error/timing implications.  You noted images of two different rules in your post triggered on Value Changes for Clone Status, and indicate the rule has a sibling rule in the other project.

I recommend pausing first to identify each rule which could be triggered on the change to clone status.  And, which could trigger another rule for other reasons.

I note that because I wonder if the clone action is implemented in the rule engine to happen in two steps: clone, and then edit any fields noted in the clone.  If that is indeed the case the first step of clone could immediately trigger the other rule because its Clone Status value indicates to do so.

Best regards,

Bill

Like Trudy Claspill likes this

Thanks Bill....
By placing a Clone Status equals check after the Edit issue fields where Clone Status is set to "Has Clone" it will not pass that point - which implies either the field never gets set, or as you suggested, the field is not yet changed before the clone block occurs, which brings in the "To Clone" value, which triggers the other rule. I don't suppose there is a wait timer available here?

Like Bill Sheboy likes this

Great catch @Bill Sheboy !  I hope I would've gotten to that conclusion eventually. :)

Like Bill Sheboy likes this

Gene, for some timing issues, the action Re-fetch can help.  For example, when triggered on issue create I usually put a Re-fetch after the trigger: the API call from the rule engine seems to catch the event before the complete issue is available.  And Re-fetch thus slows everything down a bit (i.e. seconds slower).

For your use case, this seems more like an algorithm problem.  One way to solve it would be to use two different values (semaphores) for that field, based on the target project.  Such as "Clone to Project A", and "Clone to Project B".  The rule in each project would appropriately detect the sibling project source to prevent collisions.

Another way would be to check who triggered the rule {{initiator}} is what you expect, and not continue if it was automation versus a person doing an edit.

 

Trudy, sorry if I walked on your answerin'  I'll wait a bit longer before jumping in next time.  :^)

I welcome the assist. But you won't get credit for the answer when your posts are included in my answer thread. :-P

Bill & Trudy,

 Thank you for your help. As per Bill's recommendation, I added two differing values in the Clone Status field and used each as a trigger in the appropriate rule. Worked like a charm!

Like Bill Sheboy likes this
1 vote
Ravi Sagar Community Leader Apr 30, 2021

Hi @Gene LaMantia 

Try not using "For Most recently created issue".

Ravi

@Ravi Sagar 

Thanks for you help here and on YouTube. I have a requirement please help mw with this.

How can I automate the clone of anissues with attachments and comments to another project?

 

I need to move issues from Project A to the Project B automatically when status is changed.

I would like to create a rule that does the following:


Designer changes status from Prod grooming to Team Backlog status In project A >Then  Deep clones issue (with attachments and comments) to Project B.

Hi @Johnson Aduri ,

With our Jira cloud app Deep Clone for Jira you can clone issues with attachments and comments to another project.

It's also possible to automate cloning by adding a Deep Clone post-function or integrate it with Jira automation.

If you have questions or feedback about our app, don't hesitate to get in touch with us.

Like Johnson Aduri likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
Community showcase
Published in Jira

Admins, notify your Jira instance of system-wide changes with the new admin announcement banner

Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across their  Jira Cloud instance.  ...

689 views 17 19
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you