Project

General

Profile

Actions

Feature #4585

open

Move a Version from one project to another

Added by Martin Lindhe about 14 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
-
Start date:
2010-01-14
Due date:
% Done:

0%

Estimated time:
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-projectsNew2011-08-05

Actions
Actions #1

Updated by Martin Lindhe about 14 years ago

Forgot to mention we are using svn trunk of redmine.

Actions #2

Updated by Martin Lindhe about 14 years ago

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

Actions #3

Updated by yac yac almost 11 years ago

+1

Actions #4

Updated by Joel SCHAAL almost 11 years ago

+1

Actions #5

Updated by Toshi MARUYAMA almost 11 years ago

  • Category set to Roadmap
Actions #6

Updated by Dipan Mehta over 10 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.

Actions #7

Updated by Asaf H almost 10 years ago

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

Actions #8

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Tyler Rose over 8 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
Actions #10

Updated by Dipan Mehta almost 8 years 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!

Actions #11

Updated by Darko Palic over 5 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

Actions

Also available in: Atom PDF