Automation rule - cloning to another project making two clones?

[Gene LaMantia]

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?

[Trudy Claspill · Accepted solution]

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

Can you show us your rule, please?

[Gene LaMantia]

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.

[Trudy Claspill]

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?

[Gene LaMantia]

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"

[Trudy Claspill]

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

[Gene LaMantia]

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.

[Bill Sheboy]

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

[Gene LaMantia]

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?

[Trudy Claspill]

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

[Bill Sheboy]

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.  :^)

[Trudy Claspill]

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

[Gene LaMantia]

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!

[Ravi Sagar _Sparxsys_]

Hi @Gene LaMantia 

Try not using "For Most recently created issue".

Ravi

[Johnson Aduri]

@Ravi Sagar _Sparxsys_ 

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.

[Marlene Kegel - codefortynine]

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.

[Johnson Aduri]

@Marlene Kegel - codefortynine  Thanks.