Redmine

Forgot to mention we are using svn trunk of redmine.

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

+1

+1

+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.

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

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

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!

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

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?