Feature #4585

Move a Version from one project to another

Added by Martin Lindhe almost 8 years ago. Updated over 1 year ago.

Status:NewStart date:2010-01-14
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Roadmap
Target version:-
Resolution:

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

Related to Redmine - Feature #8991: Nested versions for projects with sub-projects New 2011-08-05

History

#1 Updated by Martin Lindhe almost 8 years ago

Forgot to mention we are using svn trunk of redmine.

#2 Updated by Martin Lindhe over 7 years ago

I solved our issue by editing redmine database, version table and change project_id to the correct one

#3 Updated by yac yac over 4 years ago

+1

#4 Updated by Joel SCHAAL over 4 years ago

+1

#5 Updated by Toshi MARUYAMA over 4 years ago

  • Category set to Roadmap

#6 Updated by Dipan Mehta almost 4 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.

#7 Updated by Asaf H over 3 years ago

+1. Related (versions as first class citizens): #8991

#8 Updated by Toshi MARUYAMA over 3 years ago

  • Related to Feature #8991: Nested versions for projects with sub-projects added

#9 Updated by Tyler Rose about 2 years ago

There is a fairly easy work around without having to go into the database ...

  1. Create a new target version in the new project.
  2. Browse to the old target version
  3. Move the issues to the new project if necessary (batch operation by shift click and right click)
  4. Assign new target version
  5. Delete old target version

#10 Updated by Dipan Mehta over 1 year ago

Tyler Rose wrote:

There is a fairly easy work around without having to go into the database ...

  1. Create a new target version in the new project.
  2. Browse to the old target version
  3. Move the issues to the new project if necessary (batch operation by shift click and right click)
  4. Assign new target version
  5. 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!

Also available in: Atom PDF