Patch #5510

Enable Mutliple Versions Per Issue

Added by Charlie Savage over 7 years ago. Updated over 2 years ago.

Status:ResolvedStart date:2010-05-12
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Roadmap
Target version:-

Description

Attached is a patch against head (as of today) that enables multiple versions per issue. If there is interest, we would be happy to do what is necessary to integrate this into Redmine core. I've attached a screen shot of the issue page so people can see what it looks like.

There have been several past discussions about supporting multiple versions per issue - see #1675, #284, #1266.

In our use case, we have 60 projects, each of which has 7 phases (each a version) and work orders (each a version) and weekly development releases (global versions). Thus an issue can be added to the May 14th development release, added to Phase I and added to a work order. Basically, we find versions a great way to group issues together to a) keep track of progress b) roll up time entries c) roll up estimated times.

A quick over of the patch:

  • Because it changes models, controller and views, its not really workable as a plugin
  • It adds a new table, issues_versions, with issue_id and version_id columns. This is a habtm relationship between versions and issues. This could be done as :has_many :through if that is preferable.
  • It includes migrations to setup the new table and then renames the fixed_version_id column in issues to fixed_version_id_old (so as to not delete the data). Note that as far as I can tell, rails migrations don't allow the creation of a two column habtm table with both fields as primary keys, thus part of the migration is in sql currently (tested on postgresql).
  • It adds a new issue_version controller modeled after issue_relation as well as the necessary controller permissions.
  • It updates all the various places issue.fixed_version is used (issue update form, mass edit form, move form, reports, etc).
  • The ugliest part of the patch is Issue#by_version since it has to repeat code from Issue#count_and_group_by which isn't flexible enough for this change.

The one caveat of the patch is time reports. These reports remain unchanged if you do not group by version. But if you group by version, and add an issue to two versions, then its time is added to both versions. That is exactly the behavior we want, but it might not be appropriate in all cases. The easy way to avoid it is don't add an issue to two versions (or if you do, don't sum up the times between the two versions). Or in other words, multiple versions give a great deal more flexibility to managing a product, but you do have to understand what you are doing.

Like I said, if there is interest we'd like to see this integrated into Redmine core and are happy to make changes/update tests, etc. to make it happen. Note we've been running the patch in production for a couple days now, so believe it works as designed. We'll keep the patch updated against head, and fix any issues that we run into obvously.

versions.patch Magnifier (41.7 KB) Charlie Savage, 2010-05-12 08:14

multiple_versions.png (127 KB) Charlie Savage, 2010-05-12 08:14


Related issues

Related to Redmine - Feature #1266: Feature: Allow setting multiple target-milestones New 2008-05-20
Related to Redmine - Patch #219: Issues fixed in multiple versions New

History

#1 Updated by Nick Read over 7 years ago

Looks awesome! I'll try and get around to testing it out some time this week.

#2 Updated by Charlie Savage over 7 years ago

Question - why is this issue marked as resolved? Does that means it has been rejected?

#3 Updated by Stefano Lenzi about 7 years ago

What does resolved for an issue means if it has not been integrated in any redmine release after that it reached the resolved state?

Should we re-open it?

#4 Updated by Terence Mill about 6 years ago

In general multiselect switch feature should be possible for all fields, also custom fields of type list or enumeration.

#5 Updated by Rick Barrette over 5 years ago

This feature would be usesfull for my company, as we have several applications that share code from library projects. I would love to be able to assign an library issue to the roadmaps of all effected applications.

Also I am also curious why this is issue has been marked as resolved, when it clearly has not been merged into the trunk.

#6 Updated by Alex Bevilacqua over 5 years ago

Can this be re-opened? This would be a very useful feature for a lot of users

#7 Updated by Etienne Massip over 5 years ago

  • Status changed from Resolved to New

#8 Updated by Eraldo Girardi about 5 years ago

+1
Hope this feature could really be integrated into Redmine. It's so useful for my company because we have to mantain a lot of versions (related to branches) and issues often always involves more than one.
Thank you.

#9 Updated by Toshi MARUYAMA over 4 years ago

  • Category changed from Issues to Roadmap

#10 Updated by Alice Etchegaray over 3 years ago

I tried your patch Charlie, but it seems it isn't adapted for versions 2.X ...
Can you upgrade this ?
Because this feature can be very useful for my company..

Thank in advance.

#11 Updated by Toshi MARUYAMA about 3 years ago

  • Related to Patch #219: Issues fixed in multiple versions added

#12 Updated by Alex Shemshurenko over 2 years ago

Hi.
Ive tried to apply the patch on 2.5.2 and patch failed.
Any ideas how to get this functionality working.Plugins maybe?

#13 Updated by Charlie Savage over 2 years ago

  • Status changed from New to Resolved

Hi all - yes that's a patch I developed a long time ago but haven't updated since. Probably best to just close this ticket, and if someone wants similar functionality to start from scratch.

#14 Updated by Alex Shemshurenko over 2 years ago

Hi Charlie Savage
Ill try to re implement it.I dont know why redmine does not have such functionality, seems like usual thing for regression fixes.
If i have a technical question regarding this project will you be able to answer them for me please? Thanks

Also available in: Atom PDF