I'm not sure what you are aiming to achieve here - projects contain issues, so in a literal reading, "move one project to another project" is nonsense. The only way I could answer it would be "move all the issues from one project to another", but that's explicitly ruled out, so I'm stuck on what you're trying to achieve.
If it is about moving the issues, then no, the issue key is always "current project - sequence".
Yes, a project merge is "move all the issues from one project to another".
You can set it up so that they remain distinct-ish - if you've got issue type A, B and C in the source project, and D, E and F in the target, and they have different configurations for fields, screens and workflows, you could add A, B and C issue types and config into the target project so the issues still work the way they did in the old project. But they'll have to take on the project key and sequence of the target project (searching their old key will still find them)
Nic, I think you meant to say that the issue key is formed by concatenating the project KEY with Issue Sequence. How hard it is to configure this logic to include Component key also as part of forming the issue key if required. For example, if a project 'PRJ' has two major components, let us say 'MAIN' and 'SRVC' and if we need to create the issues in MAIN as 'PRJ-MAIN-1' and issues in SRVC as 'PRJ-SRVC-1' ? So, this way, all Lauren needs to do is to create a component with the same name of the old project key in the target project and after the move, the key will still have reference to the old project instead of taking the project key from the target project as is. I knew this future is not available in JIRA now. But, I am curious to hear from you on this idea.
That is what I said.
It's very hard to change the key. You would need to rewrite quite a large amount of JIRA's core code, plus all the applications and add-ons to do it, rendering it not upgradable or supportable. Also, basing the key on components won't work anyway, as it's a multiple option.
Nic, In general terms, I agree with you on the statement 'components won't work anyway, as it's a multiple option', but if it should be configurable with some kind of limitation on the component key size and there should be an option of either to configure with component key or without component key to generate issue identifiers. I do understand that the back flow from add ons to JIRA may be an issue and it is more work for all the applications and add ons. Since JIRA has some limitations on hierarchy, it is impacting our ability to do many things that our clients expect.
I do currently have an immediate need with one of my client, but managing in an alternate way. Thanks.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs