Feature #685

New Custom Field "Found in Version"

Added by Sven Schuchmann almost 15 years ago. Updated over 1 year ago.

Status:ClosedStart date:2008-02-18
Priority:NormalDue date:
Assignee:-% Done:


Category:Custom fields
Target 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.

affected-version.patch Magnifier (18.6 KB) Brian Lindahl, 2011-01-06 01:23

found-version.patch Magnifier - v1.0.4 patch file for 'Found in version' feature (18.6 KB) Brian Lindahl, 2011-01-06 01:36

Related issues

Related to Redmine - Feature #1675: Add 'affected version' as a standard field Closed 2008-07-23
Related to Redmine - Patch #7443: Found-in-version patch Closed 2011-01-25
Related to Redmine - Feature #18560: Show issues with custom field of type Version as related ... New
Related to Redmine - Feature #2096: Custom fields referencing system tables (users and versio... Closed 2008-10-27
Duplicated by Redmine - Feature #14250: BugTracker enhancement: allow to create a custom field fo... Closed


#1 Updated by Thomas Lecavelier almost 15 years ago

Hi Sven,

As you said it, it would be a custom field. Custom fields can be created by your redmine administrator. But maybe I hadn't understand your point?

#2 Updated by Sven Schuchmann almost 15 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.

#3 Updated by Thomas Lecavelier almost 15 years ago

Ok, so the feature request is more a "add project based data sources for custom field", like Version, affected users and so on... Maybe could we enumerate here all datas that should feed a list in a custom field?

#4 Updated by Sven Schuchmann almost 15 years ago

In my opinion that would only be two:
- Versions in a project
- Users assigned to a project

Or am I missing some?

#5 Updated by Sven Schuchmann almost 15 years ago

Just want to keep this alive...

#6 Updated by Sven Schuchmann over 14 years ago

  • Target version set to 0.8

#7 Updated by Thomas Lecavelier over 14 years ago

  • Target version deleted (0.8)

Reset "target version" field.
It's not the proper way to get a feature implemented...

#8 Updated by Bram Verburg over 14 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?

#9 Updated by James Turnbull over 14 years ago

Also interested in this feature - would be very useful.

#10 Updated by Jani Tiainen over 14 years ago


Would be very useful feature to be able to populate custom field from standard project data like versions. It's not a big problem to populate lists by hand but still it feels stupid to do that.

#11 Updated by Michael Aye about 14 years ago

For me it would be enough to have the possibility of a enumerated custom field. I could fill it myself with data, doesn't have to be project data.

#12 Updated by gabriel scolan almost 14 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 almost 14 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 over 13 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.

#15 Updated by Sven Schuchmann about 13 years ago

This could be the same like #2096

#17 Updated by Gábor Péntek over 12 years ago


#18 Updated by Nicholas Kulikov over 12 years ago

+1 :)

#19 Updated by wAy sen over 12 years ago

+1 :-)

#20 Updated by André Jonsson over 12 years ago

This is quite useful in many situations. +1 :)
And having it generalized as "feed custom field with project data (somehow)" sounds like a very nice and flexible idea to go about it.

#21 Updated by Brian Lindahl about 12 years ago

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?
/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!

#22 Updated by Brian Lindahl about 12 years ago

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.

#23 Updated by Brian Lindahl about 12 years ago

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

#25 Updated by Judicaël Bedouet over 10 years ago


#26 Updated by Sébastien Aubry over 10 years ago


#27 Updated by Dipan Mehta almost 10 years ago

How is this issue any different from #2096, which is already in the release?

#28 Updated by Judicaël Bedouet about 9 years ago

You are right. I have just created a custom field "Found in version" which fulfils the description of this issue.

#29 Updated by Jakub Rusiecki about 7 years ago

Hi all,
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 over 6 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 over 6 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.

Following issues have almost the same demands: Do add related

#32 Updated by Toshi MARUYAMA over 6 years ago

  • Category changed from Issues to Custom fields
  • Assignee deleted (Jean-Philippe Lang)

#33 Updated by Toshi MARUYAMA over 6 years ago

  • Duplicated by Feature #14250: BugTracker enhancement: allow to create a custom field for "occours in version" - end of Life added

#34 Updated by Toshi MARUYAMA over 6 years ago

  • Related to Feature #18560: Show issues with custom field of type Version as related issues in the Roadmap added

#35 Updated by Philippe Cloutier almost 2 years ago

Sven, this would be useful, but can you clarify why you ask this to be a custom field? I understand that being able to create such a custom field would be an improvement, but would a standard field not address your use case?

#36 Updated by Sven Schuchmann almost 2 years ago

Hello Philippe,

I opend this ticket 13 Years ago... I think in the meanwhile you can close
it since there a new custom field type "version" which fits my needs :-)

Best Regards,


#37 Updated by Go MAEDA over 1 year ago

  • Status changed from New to Closed
  • Resolution set to Duplicate

Sven Schuchmann wrote:

I opend this ticket 13 Years ago... I think in the meanwhile you can close
it since there a new custom field type "version" which fits my needs :-)

Thank you for the feedback and I am glad to see that your original request has been fulfilled with #2096. I am closing this issue.

#38 Updated by Go MAEDA over 1 year ago

  • Related to Feature #2096: Custom fields referencing system tables (users and versions) added

Also available in: Atom PDF