Bulk Clone In Jira Cloud

[Rakesh_Jajper]

Hi team,

We are trying different options for cloning issues - Scriptrunner - clone issue, Deep clone etc and running into some issues to keep issue number same like original project.

After deep diving we found out that issue keys for cloned projects are not matching with original issue.

For example: in URS if issue number is URS-19734, somehow in cloned project its assigning different number: SRP-17711 instead SRP-19734

Anyone got similar issues? Any suggestions how we can fix this?

We have requirement to keep the same number in different project as there are many places they refer this numbers? Project key will vary but we want the number to be same

Thanks

Rakesh

[Alex Koxaras _Relational_]

Hi @Rakesh_Jajper and welcome to the community,

Apps will clone issues just fine and will copy all field to their destinations. However, project key is another thing and is not controlled by any app, just by Jira. Project key is an incremental number, which can't be altered, zero-ed, or reduced. Once you start a project and create an issue, this will start counting. With that said, most likely I assume that on your replica project

• you had already some issues there,
• the users created new issues (subtasks etc),
• or there could be a problem with the configuration of the cloning app (e.g. you didn't choose to clone all issues)

Hope any of the above helps!

[Rakesh_Jajper]

Thank you all for your reply and I understand what you are saying. 

But we have requirements to clone tickets with same number. Both projects will be separate.

If anyone knew such thing please share.

[Curt Holley]

Cheers @Rakesh_Jajper 

The only way I can think of (and it may not meet your needs or even work) would be to create a new empty project and export the entire source project and import it  into the new one. 

I actually have no idea if it would load them all in the same order (I'd start by ensuring they are sorted by Key in the CSV (or whatever format) experiment and take it from there. 
If not all are required, then perhaps label the keepers somehow so it is easier to bulk delete the excess.

This is isn't a very elegant or practical solution (even if it works), but best I can think of.

Good luck!! 

[Curt Holley]

HI @Rakesh_Jajper 

I second what @Alex Koxaras _Relational_ has said and will add......Why?

Why all this cloning? If the key of the original is so important, why not simply link back to that issue for any subsequent issues that happen to (for some reason or another) need exactly the same information.

I'm unsure and somewhat concerned about why you would require all of this "Bulk cloning". What is the use case? Why is the exact same issue required in multiple projects? What about using a parent Epic and having multiple children stories across multiple projects as a way to organise the structure of this carbon copy work you are doing?

[Alex Koxaras _Relational_]

@Curt Holley cloning an issue and the reasons behind it are not of our concern. They might have strict policies about this. They might even have two jira instances in which you clones the issues to a more secure environment, accessed only by a few.

[Curt Holley]

Just being curious @Alex Koxaras _Relational_ and I've often found asking why can help people realize (perhaps) there is another way that is better suited for the purpose. Also I'm interested in what use there may in-fact be.

Speaking of curiosity, can you simply clone between cloud instances, rather than export/import or migration?? Is that a handy scriptrunner trick?

[Alex Koxaras _Relational_]

@Curt Holley maybe it's how I read your answer, why I replied to you. I get your curiosity. I have a client who has two (server) instances. He has a JSM project and a 20+ software projects for their products. The customer opens a ticket. The agent decides about what project it is about and IF a software ticket must be raise (bug. fix, improvement etc). Then the agent creates a "dev" issue in one of the software projects. This issue is synced to an internal jira instance, where all the devs works. Whatever the devs do in the inside instance is reflected to the outside (with respect to the statuses). If the dev wants to "push" a comment to the outside instance, he/she uses a transition which pushes this comment to the outside world.

And this internal system is very strict. We don't have access and we so team sessions (monitored) to do our work when needed. Sensitive information and stuff..

[Marlene Kegel - codefortynine]

@Curt Holley , I am the product manager of Deep Clone for Jira, which has all the users who love "all the cloning" :) 

Our app also allows to clone between two or more cloud instances. Once set up, the process is pretty easy and can be done by any Jira user (if s/he has the permission).

It's actually a valid use case and I predict that it will be used more and more in future, with the current development towards Jira cloud and smaller instances. 

[Curt Holley]

Cheers @Marlene Kegel - codefortynine Yes!! I can certainly imagine inter-instance cloning use cases and of course, even inner-instance ones as well.

Which reminds me @Rakesh_Jajper I did have a thought that might be helpful for you, as I fear your attempts to clone and have matching key numbering will prove very complicated....to say the least! 

What about building a custom field and a cloning automation rule that populates the original key (or even just it's numbers) into it, so that it can be used as the unique identifier, instead of try to have matching keys across multiple projects/instances.