Hi,
I changed the keys of my team-managed projects; I observed that the issue keys also changed.
I'm trying to create a new company-managed project with the original project key so that I can migrate the issues of the old team-managed project. However, I can not use the original project key which I need to use for consistency.
I thought maybe there are some processes running in the background after the renaming, but two days later nothing has changed. By renaming the key, I am assuming that the key should become available again which is a logical consequence.
When trying to create a new company-managed project with the original key, I'm getting the error message that a team-managed project already has the given key; however, when opening the project settings, it doesn't.
Therefore, there is a huge inconsistency between what is communicated on the UI and what happens in the background, therefore it is non-intuitive what actions I should take to achieve the outcome I want.
Any workarounds? Thanks!
Hi @Anton ,
@Marc - Devoteamis right. You can't do it that way.
You could however use an .csv export of the old project, delete it and try to import the issues in the new company managed project.
I'm certain you wont get the same issue keys, but at least you'll have the same Project Key.
Why do you need the exact issue keys in your new project?
Cheers
Max
That sounds indeed like a good workaround.
We are using issue keys as actual references to user stories in documents and conversations, internal and external.
Therefore, if the keys will be different, it might create a lot of inconsistencies in other places and also chronologically it messes things up.
Thanks for the hint!
Anton
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Anton
No.
There can't be 2 projects in the same instance with the same key.
Changing the key on a project will still retain the old key in the system as old links will still need to work.
Only if you completely delete a project the key will be released.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Considering that the final release happens with the deletion, it means that
What's left is one company-based project with Key1, while there are no references through Key1 to the team-based project, however, there might be Key2 somewhere it the system still referencing the company-based project, which means, that optimally I would add a buffer project:
What I don't know is if issues preserve their code during migration
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Anton
You can execute the 1st 5 steps.
You would only have a reference to key2, based on the migrated issues.
To be completely clean, you would indeed need to take the 7 step action.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.