You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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
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
Hope any of the above helps!
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.
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.
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..
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.
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.