Help on unique automation requirement

[Don Hames]

I am currently using the Data Center version of Jira and migrating later this year to Jira Cloud. I can not wait until the migration to solve this, so forgive this question if it is not in the right section to ask.

I am having issues with writing the automation for the following scenario:

I have two projects; project A and project B

Project A contains several Epics; each Epic has several child Stories.

Project B is empty.

I need automation to find a specific Epic (I know the key) in Project A and clone it into Project B. Cloning an Epic does not add the children Stories, so here are my attempts to recreate the Epic Story relationship in Project B.

Then I need automation to find specific Stories (children of the Epic above, and I know the key for each) and clone each into Project B.

I have tried several ways, but cloning adds a unique challenge as you must find the issue you want to clone. Is there an automation component that allows you to specify a key and locate it so it can be cloned?

If I was creating issues, it's straightforward. You create a new Epic. Add a branch rule for the most recently created issue. To create the Stories, you create a new Story, and in the additional fields, you set the epic link to the new Epic. The following line sets the Story epic link to the just created Epic.

 "epic link": {{issue.key.asJsonString}},

I can not find a way to locate an issue, in this case, an Epic with a known key, clone the Epic, and then clone the children by using the keys and be able to set the epic link as above for creating a Story.

Has anyone tried this before and has a solution? If so, I would appreciate your insight into solving this.

[Trudy Claspill]

Hello @Don Hames 

Are you always cloning the same Epic and the same child stories?

Do you need to be able to do this on demand (i.e. manual trigger), based on another issue event, or could it be done on a schedule?

[Don Hames]

Hi Trudy. Yes, I have a fixed set of Epics and Stories I am using as templates. It needs to be done on demand via a manual trigger. 

I have the system working by creating the Epics and Stories instead of cloning, but I want the content to be controlled through the templates and not have to update the automation rules whenever they update a template.

I have the template Epic issue keys and the child Stories issue keys. It seems simple, but having the automation go to a specific issue, i.e., an Epic seems clumsy. At least the ways I have tried.

[Trudy Claspill]

I'm still thinking about ways to accomplish this, but here is one method.

In the past when I needed to do something similar, I would use Advanced Issue Search to retrieve the Epic and child issues I wanted. I would then use the CSV export to export those issues. I would then manually tweak the file content with regard to issue IDs so that I could use CSV Import to create the issues anew based on the exported CSV.

I exported the issues fresh each time before importing them to get the latest "templated" information in the issues.

[Trudy Claspill]

Still thinking on this...

Are you cloning all Stories under a given Epic, or only a subset of the child stories? If a subset, will it always be the same Stories in a given epic or might the selection of child stories change periodically?

Is the destination project going to be different each time you run the rule?

To trigger such a rule manually you need to either be in an issue already from which you can trigger the rule, or you need a Scheduled Trigger rule. You could have the  Scheduled Trigger rule disabled normally, and then re-enable it and trigger it manually from the Automation Rules page when you need it.

So, for instance, you might be in the Epic you want to clone, and trigger the rule from there. But if the destination project can vary, then how would the Automation rule know in which project to create the issues?

I'm brainstorming on ways this might be accomplished. I haven't fully worked out any of them.

1. In the destination project create an issue that has in it a field where you would specify the issue key for the Epic needing to be cloned. Have a rule triggered on creation of an issue in that destination project with that field being not empty. That rule would execute tasks to clone the desired Epic.

1.a. The creation of that Epic in the destination project with the "clones" link to the original Epic triggers another rule that executes the steps to clone the selected child issues.

2. Use a unique custom field value for each Epic/Child Issues group. That value might be usable to retrieve the issues (maybe using one or more Lookup Issues actions) in a way that would allow the retrieved list to be iterated over to clone each of the retrieved issues. Maybe lookup the Epic first, clone it, and create a variable to note the key of the newly created Epic. Then lookup the child issues, clone them, and use the previous variable to set the parent epic for each newly created child issue.

This is a more complex issue creation/cloning process than I've ever had to work out. There are probably better ways to accomplish it with an automation rule than have occurred to me so far.

[Don Hames]

Trudy, indeed it is. I have tried several variations of your suggestion and a few of mine. I think I am closer than I was. I can clone the specific Epic without the child Stories and clone the child Stories since I know their key.

The current problem is I can not figure out a way with smart values or anything else that will allow me to take field values from the Epic or Story being cloned.

Specifically, the Epic belongs to a Feature. The Feature is what triggers the automation rules. I use the Ralated issue rule with JQL to position the issue to be cloned. The clone works, but the {{iisue.fieldname}} always goes back to the Feature, not the Epic.

I will keep working on this since it must be solved. Thanks for the suggestions. If I find an answer, I will post the solution here.

[Trudy Claspill]

Can you share with us the rule you have so far?

[Don Hames]

Sure, can you add a screenshot here? I can't find how and I think screenshots will communicate the process better. Do you know how to embed screenshots into the texts?

[Trudy Claspill]

Yes you can attach files to the posts/comments in the community 

[Don Hames]

I think I have tracked my current issue down, and it comes to a simple "How do you do that?"

If you have a Feature that triggers an automation rule, that feature becomes what Jira calls the "current issue." I want to use a different issue in the same project, such as an Epic I want to clone.

How do you make the Epic (I have the key) the current issue? Without being able to change the current issue, all smart values such as {{issue. or {{triggerIssue refer back to the Feature, even though I am cloning the Epic.

I used an Issue condition with the related issues condition, selected JQL issues, and entered the JQL "key = MRM-441".  If you create an active component of Close Issue, it will clone MRM-441, but all the smart values retrieve the data from the Feature. If I do not specify a specific field and set its value in the Addition fields Json entry, even though the Epic has a value in that field, it does not copy or clone over to the new Epic.

I think you would need the ability to have an issue fire a trigger and then work on other issues unrelated to the trigger issue. Do you know if that can be done?

[Trudy Claspill]

When you use a Branch/Related Issues/JQL, within that branch use of the {{issue}} smart value should refer to the issue selected by the branch. So, if your JQL selects Epics related to the Feature, then you should be able to include a Clone action within that branch, and use {{issue}} to reference fields in the Epic and {{triggerIssue}} to reference fields in the Feature that triggered the rule.

You can't nest a branch within a branch so you would not be able to include steps in that first branch to retrieve and clone child issues of the Epic(s) selected by the first branch.

You could potentially have a second rule that operates on the destination projects that is triggered by Issue Created. Add conditions that check if it was an Epic that was created, and if that Epic has a "clones" link back to one of your template Epics. If it does, then you can use that information to retrieve child issues from the source Epic, clone them into the destination project, and link them to the Epic (in the destination project) which triggered this second rule.

These rules would have to be multi-project rules, so you need to consider if the triggering of the second rule in particular might run you into the Global Rule Execution limits.

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/