Patch #219: Issues fixed in multiple versions - Redmine

Actions

Copy link

Patch #219

open

Issues fixed in multiple versions

Added by Nick Read over 17 years ago. Updated almost 6 years ago.

Status:

New

Priority:

Normal

Assignee:

Category:

Roadmap

Target version:

Start date:

Due date:

% Done:

Estimated time:

Description

The attached patch allows for issues to be fixed for multiple versions. Some notes concerning this patch:

There is a couple of new language string that need translating

The change log implementation was modified to work in the same way as the roadmap (but with different functionality
of course). This was simply to avoid doing extra joins from issues to versions across the additional join table. The
controller and view of change log and roadmap have a lot of common code now that could be refactored.

The migration will only revert if each issue is marked as fixed in only one version, else it will raise
an exception.

The version selector is a HTML select list with multiple selections turned on. There are usability studies indicating
that these are difficult to use, and having a list of checkboxes maybe a better option. There are plugins for doing
this sort of thing, but I didn't really want to include a plugin as part of the patch :)

Files

multiple_fixed_versions.patch (11.9 KB) multiple_fixed_versions.patch

Nick Read, 2008-02-03 11:00

Related issues

Actions

Copy link

Updated by Nick Read over 17 years ago

This patch implements feature request #9196

http://rubyforge.org/tracker/index.php?func=detail&aid=9196%a
mp;group_id=1850&atid=7163

Actions

Copy link

Updated by Nick Read over 17 years ago

Hi Jean-Philippe,

I am wondering if you are averse to the functionality
provided by this patch?

The current inability to record this information is pretty
much a show-stopper for my company. If we were to take up
redMine (which is looking quite likely at this time) then I
would have to maintain and apply this patch every time we
upgrade.

Is there anything else I can do to help this functionality
through? Does it conflict with other areas of redMine
(gantt chart, reports, ...)?

That said, I suspect that trunk has changed a lot since this
patch was first submitted, and I would have to update it to
ensure that it merges without conflicts.

It would be great to get your response, whether it is
affirmative or negative.

Thanks,

Actions

Copy link

Updated by Jean-Philippe Lang over 17 years ago

Hi Nick,
I'll have a deeper look at your patch this week-end, so I can
give you an answer. Maybe I'll add a setting to allow issues
to be fixed in multiple version.

BTW, do you find the Changelog view usefull ? In the current
code, past versions can also be viewed on the roadmap, so I'm
thinking about removing this view... Any feedback appreciated :-)

Regards

Actions

Copy link

Updated by Nick Read over 17 years ago

Thanks Jean-Philippe; that would be great. I suspect the
patch will not merge anymore, so tell me if you want it
rewritten for the current trunk. A setting to
allow/disallow this feature is good.

As far as the Change Log goes, I completely agree. It is
not very often that I require a view of what has been
released, only what needs to be done. That makes sense
given that I'm a developer, but our marketing people would
be more likely to need a list of what has been completed!

A good compromise would be to remove the Change Log
functionality, but provide a persistent URL for viewing the
details of a single release in the Roadmap view, even if the
release has been completed. This would allow users to
create wiki pages, news items or forum posts regarding a new
release of the product, and provide a link to the
roadmap/changelog of just that release. eg,

http://demo.redmine.org/projects/roadmap/3/specific-release-id

Actions

Copy link