Redmine

Related this to issue 1245 as the issue came up in the comments for that issue too.

+1 Though this seems to be also becoming difficult due to the fact that you can have multiple branches (versions) out in the field which are indeed affected by one issue. Also those versions can be "closed" already.

So do we allow this "affected version" field to contain multiple versions for one issue? And do we allow issues with the affected version set to a "closed" version?

Also important to mention in this issue is that this "affected version" field should ideally populate it's contents from the project's versions...

I think it is enough to allow only one version to be affected.

I already mentioned a "found in version" field which seems to be the same as "affected version" over here #685

Sven Schuchmann wrote:

I think it is enough to allow only one version to be affected.

Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.

This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.

Nick Read wrote:

Sven Schuchmann wrote:

I think it is enough to allow only one version to be affected.

Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.

This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.

I agree with Nick.

Nick Read wrote:

Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.

This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.

While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.

I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.

Cheers

Russell

I just want to cast my vote for this feature.

Russell Hind wrote:

Nick Read wrote:

Strongly disagree. Working on a large project that has many version in the field, it is common that an issue is reported by different customers and affect multiple released versions. Add to this any unreleased versions that our internal QA team finds.

This same logic can (and should) be applied for multiple fixed versions (for different branches), as can be seen in my feature request in #284 and comment in #1266.

While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.

I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.

If you look at it that way i'm going to doubt since that approach could be workable too imo. Though I'd then recommend to add a specific issue-relation for this kind of ticket-branch_relationship.

Either way it will be a change to redmine with a higher severity imo. At the moment I'd vote therefor to further discuss the pros and cons of either implementation before changing anything already :-)

Russell Hind wrote:

Nick Read wrote:

....

While I agree that issues will be found in multiple versions and also therefore fixed in multiple versions, that can already be achieved by relating tickets and therefore creating multiple tickets, one for each version it was fixed in. That way, you have a specific ticket to close when you merge the fix to the appropriate stable branch.

I'd be happy with it implemented either way, but if a single affected version and target version would make it easier (therefore quicker) to implement, then I'd be happy with that.

See comment no.3 in #1266 for my reasons against this data duplication against tickets. Tickets are not a static thing; they get added to, edited, moved around. Unless the relation type is special enough to perform automatic data updates across the related tickets, then it's not suitable. I think I'm going to have to rewrite my multi-fixed versions patch for the latest trunk - the same logic could be used for a multi-affected versions patch.

+1

+1

+1

+1. And I agree with Russell.

+1, it's absolutely needed at my company.

+1

Ticket #2081 is also related to this feature.

I don't know if this was already proposed, but what if the custom field "List" was extended in order to allow multiple selection instead of just one?

In this case, the combo box would appear with checkboxes on the side of each option, allowing multiple selection.

I think this feature would allow all requests above and the "Assign a task to multiple users" (ticket #408)

+1

This is an important feature.

Do we have any update on this request?

This is something that is very very needed. Redmine.org has it :)

It would be nice to have a custom field type that is called 'Version' so it will pick up values from project itself.
It can be the same single/multiple choice option as in filters.

+many

I am surprised this isn't implemented yet, nor has anyone bothered making a plugin for it.

As many other guys stated, this feature would be very helpful, it would allow the testers job to be integrated into the development iterations.
Please...implement it...

+1

I do believe that this would help with any of my software projects. However it should not be mandatory. I have a large number of projects that are not related to software. They just want to use this application to manage their day to day work. In fact some would like to remove a couple of the required fields that they are not using, but that is another issue. The Redmine application has proven to be an effective and simple way to manage many projects, not just software.

+1

Definitely a must have. Should've been a standard feature already. It'd be pretty easy for the affected version field to pull values from the target version anyways.. +1

+1

+1

These are very important features for us! We are a governmental software development company, we have a bit difficult product and release management, so I'd like to promote these features in the base installation. Thanks!

+100

I have to concur that this is a sorely missing and critical piece of managing projects. Manually maintained custom enumerations per-project is weak workaround that we painfully have to endure.

+1 Currently working manually.

+1, please incorporate the "Found version" patch in the trunk.

Also adding an "Affected versionS" field which could contain multiple versions would be great.

Created a patch issue to follow the progression of the 'found-version.patch' patch file I created.

+1, this is a basic feature of every TTS and the pathc is already there - please incorporate it in the release. Not everybody wants to build from sources ...

+1 it would be great!

• We are using Redmine for more than 2 years with many projects and subprojects. We tried so far to make it without any "found in" field, but we miss it more and more...
• We are also going to merge/import some Trac projects into Redmine (and Trac provides by default the 'found in' field) Too bad to lose this information during the migration...
• Could at least the Data-Model/Architecture of the patch be reviewed and validated by a Redmine core developer ? (goal: a patched system could thus smoothly be upgraded when the feature will be native in Redmine release 1.x). With no such warranty, I'm not ready to apply any patch... (maybe I'm too careful, please correct me if I'm wrong...)

What about using a Version custom field as it will be available with 1.2.0 release (see #2096) ?

Etienne Massip wrote:

What about using a Version custom field as it will be available with 1.2.0 release (see #2096) ?

Thanx a lot for the hint! (linking #2096 to #1675 as 'related' would help to know about this nice feature)
Maybe the only drawback will be that unreleased versions are also in the dropdown list (but it's not a big problem, at least for my team)
I'll study ASAP how I can manage with Trac migration...

What about 1.2.0 release date ? I noticed in RedmineInstall that Rails and Rack requirements will upgrade with 1.2.x compared to 1.1,1.0,0.9. I hope it won't be a problem to upgrade my server to be compatible with this new stack.

Gilles Cornu wrote:

• We are also going to merge/import some Trac projects into Redmine (and Trac provides by default the 'found in' field) Too bad to lose this information during the migration...

Etienne Massip wrote:

What about using a Version custom field as it will be available with 1.2.0 release (see #2096) ?

I upgraded to Redmine 1.2.0 and successfully imported Trac, with following add-ons in lib/tasks/migrate_from_trac.rake

IMHO, this ticket could now be closed since single-affected-version is possible to configure with Redmine ≥ 1.2.0

Thanx and Congratulations!

Hello,

- I would like to install the proposed patchs, but I don't know how to do? Could you help me please ?

- Is it possible to install them with the last version of Redmine?

Thanks.

As such, now Redmine support Version type custom field - which sufficiently apply for this stated usecase. We also use this in the same manner as well. However, in my opinion, Affected_version or origin_version MUST be standard property of the Redmine core.

1. Specifically, I would like (may be a plugin or so) about the statistic about which specific issues and versions have resulted into many bugs, (which references those affected versions).
2. One can also automatically create/link Relevant tests based on all test cases that have been applied on Affected versions.
3. One can make developer/tester assessment based on number of bugs filed against version where particular user was developer or tester.
4. One can develop software reliability matrices by combining maximum bugs affected on versions - and modules that got modified on during those versions.

Now may be many such features are far beyond the scope of the ticket describing above, and also quite a few plugins as well, but the limited point here is that "Affected version" should really be a standard attribute of bugs by all means.

After reading this and other issues i was happy to find the new type "Version" for custom fields,
but there is one big problem if you want to use this type for "found in version".

In my case the custom field of type version only show the upcoming versions and not the already closed from the past...
But for reporting bugs for already released versions, it would make sense to let the reporter choose from the old/closed versions instead of the future versions.

i think, if we would have another type like "closed versions", that should do the trick! :)

edit: while looking at redmine.org's "new issue", i was wondering if the dropdown menu is configured as a list (manually maintained?!) or if there is a trick to let the type Version even show the old/closed versions?!