We need to clone issues within the same project (same workflow).
The clone issue must retain the same original status of the cloned one.
We are trying to implement this feature with Automation.
The steps should be straightforward, as in the attached screenshot:
1. Trigger rule When Issue Created
2. If Link Issues present clones (within project)
3. The Transition the issue to COPY FROM ISSUE
The last COPY FROM ISSUE, as stated by the "Transition issue" action inner description, should take the status from the cloned issue and try to use it as destination status for the clone one.
Both cloned and clone issues share the same workflow.
In the workflow the "Automation for Jira" actor is enabled for transition.
The transition from created status to destination status exist.
However the last action (the Transition itself) of the rule fails with this log:
You can also try the following:
If issues are always cloned into a specific status, you can put an "All" transition on it, and direct the clone to do so.
The problem with clones using automation is that in flows, it only follows the transition lines step by step, they cannot read other transitions further away and walk the path to them.
I found a crude solution by myself, even if it is not working in 100% of cases.
For the destination status of the last transition action I used the Smart Value:
{{issue.issuelinks.first.outwardIssue.status}}
I had to copy and paste the Smart Value string in the destination status selection field.
Trying to type the text does not work... (?)
I also added some "global hidden transition" in the workflow, allowed only to the atlassian-addons-project-access group (i.e. Automation for Jira)
Luckily, IF the clone ticket is not created with the cloning links feature flagged, the only related link in the outwardIssue list is the original cloned ticket.
So we can read its status and use it for the transition.
However it is very strange (a bug) that the same value is not read / accessible properly using the COPY FROM ISSUE value.
I also had to add some Re-fetch issue data actions in order to delay the last actions and to be sure that all fields in the clone issue have been populated by the time the rule tries to read them.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.