New Custom Field "Found in Version"
I think it would be great to have a custom field "Found in Version"
which contains a drop down Box with the versions like in "Fixed version".
The point is that our Testers create defect Tickets and they
should be able to choose the version in which the defect occured.
This would then be the field "Found in Version".
The developers look at the ticket a write down their comment
and estimated effort.
The managers decide in which version this should be fixed with "Fixed Version" Field.
This also appears in the roadmap then (as it is done now).
Reversly you would be able to see how many defects occured in an already
finished version with the "Found in Version" Field.
#2 Updated by Sven Schuchmann about 11 years ago
Your are right, this would be a custom field.
But the custom field should be a drop down list
with a all versions of the current project
(like "Fixed version").
At this time I am only able to create a custom field of
type "list" and enter all versions by Hand.
#8 Updated by Bram Verburg almost 11 years ago
This one is important for me too, since I know this will be a show-stopper for replacing Bugzilla with Redmine in my organization. I started working on a patch and I could use some input.
I added the following custom field types: users, projects, sub-projects, versions and members. I also added a mechanism to limit types to certain places (e.g. sub-projects, versions and members only work in the context of issues and projects, so they shouldn't be available as a custom field for users).
The problem with projects (and sub-projects) is that projects may be private, and therefore different users will see different lists. Should I drop these two field types, or would be it acceptable to show a list that includes private projects to all users?
#12 Updated by gabriel scolan about 10 years ago
it would be also nice to refer to the repository revision on which the issue has been detected (to trace intermediate version). A solution could be to define a type of custom field as "textilizable" so reference to version, revision or anything else could be done. I won't however provide a "hard" link between the object (as the target version vs issue)
#13 Updated by Jerome Vanthournout about 10 years ago
Today in this version of Redmine, in the "New Issue" form, there is the field "Affected version" which is a drop list of the different past version.
Based on what I understood, this is a custom field with enumerated value. Am I right?
The concern with the custom field is that the new enumerated value can be change only in the administrative form.
This is a issue when the project are not managed by the administrators. So, either the custom field with enumerated value can be updated in "project setting" form or the "Affected version" field is linked with the versions of the project.
I would definitely prefer the second option.
#14 Updated by Christophe Absil almost 10 years ago
Any news for this feature ? It doesn't seem to be in next release :-(.
What I would like to have is a drop down where you can choose a released version. I like the idea to have a status on version like described in issue #1245. Depending on this status, the version would be displayed on the drop down or not.
#21 Updated by Brian Lindahl about 8 years ago
- File affected-version.patch added
Also added this same comment and patchfile to #1675.
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.
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?
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!
#22 Updated by Brian Lindahl about 8 years ago
- File 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 is was found in, and is filled in by the submitter. It can and should only be a single-selection. '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.
#29 Updated by Jakub Rusiecki over 3 years ago
The custom field is a good start. However (as of RM 2.3.3 at least) full solution should:
a) observe Version status - it should be possible to limit list of versions for which it is possible to log error
b) allow to soft available versions from most recent
as we have a lot of versions and users/testers often take wrong/old versions.
Any ideas / plugins etc. in this version 2.3.3, please ?
c) I can not delete versio associated with a ticket;
d) sometimes one can crate version per subproject and if we continue in newer project those old versions will not be on the list...
e) I know RM 3.0.3 allows to filter it by version status, but this status can not be tailored (we use another field for in Plannning, In Dev, Tests, Shipped, Discarded)
#30 Updated by Dipan Mehta almost 3 years ago
Essentially, it is not just about the "Found in Version". If there are custom fields based on version - we need qualifiers whether the fields are open, locked or closed.
I guess it would be too much to ask for that they will be restricted by "custom fields" of the version itself.
#31 Updated by Dipan Mehta almost 3 years ago
Well looks like the demand of this is really there with multiple issues.
But it can be achieved: (As I noted in other issue)
Basically, you can have a 'custom field' "Type" for each version. And then, when you define any other custom field (for issue or otherwise) which is of type version - it should ask for criteria as "field name" and values can be some conditions. If the field type has multiple values it can be selected which ones applies. The versions qualified under that condition will then be appeared in the corresponding version field.