Feature #1675
closed![Author: Anonymous](/images/anonymous.png?1679302129)
Add 'affected version' as a standard field
Added by Anonymous about 16 years ago. Updated over 7 years ago.
0%
Description
As described in this forum post , the way the Redmine project uses affected versions isn't usable by any redmine installation that has multiple projects.
Because custom fields are not on a per-project basis, we'd have to have separate 'project X affected version' and 'project Y affected version' fields as each project has different version numbers.
Affected version could be a standard field on all projects that have a 'target version' field. That way you can easily do a query on all issues that exist in a particular release.
Files
affected-version.patch (18.6 KB) affected-version.patch | v1.0.4 patch file for 'Affected Version' feature | Brian Lindahl, 2011-01-06 01:16 | |
found-version.patch (18.6 KB) found-version.patch | v1.0.4 patch file for 'Found in version' feature | Brian Lindahl, 2011-01-06 01:37 |
Related issues
Updated by Anonymous about 16 years ago
Related this to issue 1245 as the issue came up in the comments for that issue too.
Updated by Mischa The Evil about 16 years ago
+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...
Updated by Sven Schuchmann about 16 years ago
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
Updated by Anonymous about 16 years ago
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.
Updated by Mischa The Evil about 16 years ago
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.
Updated by Anonymous about 16 years ago
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
Updated by Simone Carletti about 16 years ago
I just want to cast my vote for this feature.
Updated by Mischa The Evil about 16 years ago
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 :-)
Updated by Anonymous about 16 years ago
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.
Updated by Guilherme Schneider almost 16 years ago
+1. And I agree with Russell.
Updated by Andrea Campi almost 16 years ago
+1, it's absolutely needed at my company.
Updated by Luiz Carlos Junior almost 16 years ago
Ticket #2081 is also related to this feature.
Updated by Luiz Carlos Junior almost 16 years ago
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)
Updated by Milos Zikic over 14 years ago
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.
Updated by Nathan Rijksen over 14 years ago
+many
I am surprised this isn't implemented yet, nor has anyone bothered making a plugin for it.
Updated by Roberto Marcellino about 14 years ago
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...
Updated by Curtis Stewart about 14 years ago
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.
Updated by Ве Fio almost 14 years ago
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
Updated by Brian Lindahl over 13 years ago
- File affected-version.patch affected-version.patch added
Here's a patch you can apply to redmine-1.0.4 to add the 'Affected Version' feature. You can only select 'locked' versions (in my world, these are versions that have made it past integration and internal release). It took me about 3 hours to write, since I don't know my way around the source code and this is my first work in the Ruby language.
/rant
For something SO EASY to implement, there's a terrible amount of resistance to implementing this feature. Why? If it's only because people want a multi-selection ability, and that's difficult, who cares! Since it's so EASY to implement, so INCREDIBLY useful, and so DESIRED, implement the single-selection feature now, so that people can start taking advantage of it now! When multi-selection ability is added later to 'Target Version', just add it for 'Affected Version' at the same time.
The resistance to add this feature is just a silly dragging of feet (for 2 years!!!) that I wouldn't expect to see in an open-source project. Heck, I'd be surprised to see this kind of resistance in anywhere but a government contractor waterfall-development world! Are you guys that clueless about the virtues of agile development?
/end rant
Now that I'm done ranting, I love your product... except for the lack of this incredibly important feature - it was my biggest resistance to bringing it into my company. Bring my patch into the mainline and finally resolve this issue. Thanks!
Updated by Brian Lindahl over 13 years ago
- File found-version.patch found-version.patch added
Actually, on second thought, it should be named 'Found in version'. Since 'Found in version' is quite different from 'Affected versions'. 'Found in version' is the version it was found in, and is filled in by the submitter. It can and should only be a single-selection for reproduction's sake. 'Affected versions' is filled in by the software engineers when doing version analysis, and can be (and likely is) more than one version. Here is the new patch with the different name.
Updated by Attila Antal over 13 years ago
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!
Updated by Ryan Thrash over 13 years ago
+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.
Updated by Patrick Dubois over 13 years ago
+1, please incorporate the "Found version" patch in the trunk.
Also adding an "Affected versionS" field which could contain multiple versions would be great.
Updated by Brian Lindahl over 13 years ago
Created a patch issue to follow the progression of the 'found-version.patch' patch file I created.
Updated by Axel Müller over 13 years ago
+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 ...
Updated by Gilles Cornu about 13 years ago
- 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...)
Updated by Etienne Massip about 13 years ago
Updated by Gilles Cornu about 13 years ago
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.
Updated by Gilles Cornu about 13 years ago
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!
Updated by kurumi kurogi about 13 years ago
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.
Updated by Dipan Mehta over 11 years ago
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.
Given that it would be a standard field, it makes it possible to create more functionality around it.- 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).
- One can also automatically create/link Relevant tests based on all test cases that have been applied on Affected versions.
- One can make developer/tester assessment based on number of bugs filed against version where particular user was developer or tester.
- 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.
Updated by Sebastian Denz over 11 years ago
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?!
Updated by Toshi MARUYAMA about 10 years ago
- Related to deleted (Feature #284: Issues fixed in multiple versions)
Updated by Toshi MARUYAMA about 10 years ago
- Related to Feature #284: Issues fixed in multiple versions added
Updated by Go MAEDA over 7 years ago
- Related to Feature #8572: Configuration of which versions (by version-status) are shown in version-format custom fields added
Updated by Go MAEDA over 7 years ago
- Status changed from New to Closed
- Resolution set to Fixed
Sebastian Denz wrote:
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.
In Redmine 2.5.0 and later, we can configure which status of version are shown in a version type custom field (#8572). So we can realize 'affected version' described in this issue by using version type custom field.