Feature #4585
open
Move a Version from one project to another
0%
Description
Background:
After our company started using redmine we have made some restructuring with regards to projects/subprojects.
Initially we created our first "milestone" version attached to something that was a top-level project.
After reorganization it is now a child project.
We now would like to move the association of the created version field to the top level project.
The database is populated with issues so I rather avoid to simply delete the version, create a new and re-associate all issues with the new one.
Related issues
Updated by Martin Lindhe almost 15 years ago
Forgot to mention we are using svn trunk of redmine.
Updated by Martin Lindhe almost 15 years ago
I solved our issue by editing redmine database, version table and change project_id to the correct one
Updated by 
Updated by
Updated by Dipan Mehta about 11 years ago
+1. I think it is a high time that version should become first class citizen which can be moved, journal'd and also have inheritance/hierarchy as issues and project.
Updated by Asaf H over 10 years ago
+1. Related (versions as first class citizens): #8991
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #8991: Nested versions for projects with sub-projects added
Updated by Tyler Rose about 9 years ago
There is a fairly easy work around without having to go into the database ...
- Create a new target version in the new project.
- Browse to the old target version
- Move the issues to the new project if necessary (batch operation by shift click and right click)
- Assign new target version
- Delete old target version
Updated by Dipan Mehta over 8 years ago
Tyler Rose wrote:
There is a fairly easy work around without having to go into the database ...
- Create a new target version in the new project.
- Browse to the old target version
- Move the issues to the new project if necessary (batch operation by shift click and right click)
- Assign new target version
- Delete old target version
Not at all! First off, there are often lot of custom fields associated with versions that won't be classified automatically. The versions may be closed, open and so on that will have to be manually checked in re-done. If the versions have related dates which can't be replicated.
Another big thing is the version-id. Once you recreate new version it will have new version-id. So in all places - in text fields, wikis, etc. where you have written version#id that auto expands it's title and attaches link - now you have to edit!
The users may not even know where all it has been mentioned.
The most critical part where this applies is, that when project grows bigger - you simply try to create sub-project for some parts. Now if work is partially done with some versions - and some open, it becomes impossible!
This feature is very very very very important!
Updated by Darko Palic about 6 years ago
having exactly the same issue like Dipan Mehta.
Surely I could recreate the versions, but sadly I have additional attributes in a custom plugin, which would drop all informations
Updated by Mario Gleißenberger 3 months ago
We do a lot of project management by the versions/milestones and reorganize some milestones to. Because of this milestones not only have tickets connected to one project/team. We will try to manage the milestones by the teams and milestones have to change into an other project/teams.
I will have a lock to provide a patch. To changes this in the database every time is not a solution.
The connection between milestone and project could be changes by edit the milestone?
The possible selections should be filtered by the user permissions. Otherwise the user can move a milestone to a false project and could not move it again. That's right?