Project

General

Profile

Actions

Patch #5510

open

Enable Mutliple Versions Per Issue

Added by Charlie Savage almost 14 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
-
Start date:
2010-05-12
Due date:
% Done:

0%

Estimated time:

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.


Files

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

Related issues

Related to Redmine - Feature #1266: Feature: Allow setting multiple target-milestonesNew2008-05-20

Actions
Related to Redmine - Patch #219: Issues fixed in multiple versionsNew

Actions
Actions

Also available in: Atom PDF