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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,375
Community Members
 
Community Events
176
Community Groups

Bulk Clone In Jira Cloud

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

 

3 answers

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!

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 Community Leader Feb 21, 2022

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!! 

0 votes
Curt Holley Community Leader Feb 21, 2022

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?

@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 Community Leader Feb 21, 2022

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?

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

Like Curt Holley likes this

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

Like Curt Holley likes this
Curt Holley Community Leader Feb 22, 2022

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events