Feature #685
closedNew Custom Field "Found in Version"
Added by Sven Schuchmann over 16 years ago. Updated about 3 years ago.
0%
Description
Hi,
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.
Files
affected-version.patch (18.6 KB) affected-version.patch | Brian Lindahl, 2011-01-06 01:23 | ||
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:36 |
Related issues
Updated by Thomas Lecavelier over 16 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?
Updated by Sven Schuchmann over 16 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.
Updated by Thomas Lecavelier over 16 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?
Updated by Sven Schuchmann over 16 years ago
In my opinion that would only be two:
- Versions in a project
- Users assigned to a project
Or am I missing some?
Updated by Thomas Lecavelier about 16 years ago
- Target version deleted (
0.8)
Reset "target version" field.
It's not the proper way to get a feature implemented...
Updated by Bram Verburg about 16 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?
Updated by James Turnbull about 16 years ago
Also interested in this feature - would be very useful.
Updated by Jani Tiainen about 16 years ago
+1
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.
Updated by Michael Aye over 15 years ago
+1
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.
Updated by gabriel scolan over 15 years ago
+1
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)
gabriel
Updated by Jerome Vanthournout over 15 years ago
+1
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.
Updated by Christophe Absil about 15 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.
Updated by André Jonsson almost 14 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.
Updated by Brian Lindahl over 13 years ago
- File affected-version.patch 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.
/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 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.
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. Please relate to #7443.
Updated by Dipan Mehta over 11 years ago
How is this issue any different from #2096, which is already in the release?
Updated by Judicaël Bedouet over 10 years ago
You are right. I have just created a custom field "Found in version" which fulfils the description of this issue.
Updated by Jakub Rusiecki over 8 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 ?
remarks:
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)
Updated by Dipan Mehta about 8 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.
Updated by Dipan Mehta about 8 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
#685
#14250
#18560
#17962
#20100
Updated by Toshi MARUYAMA about 8 years ago
- Category changed from Issues to Custom fields
- Assignee deleted (
Jean-Philippe Lang)
Updated by Toshi MARUYAMA about 8 years ago
- Has duplicate Feature #14250: BugTracker enhancement: allow to create a custom field for "occours in version" - end of Life added
Updated by Toshi MARUYAMA about 8 years ago
- Related to Feature #18560: Show issues with custom field of type Version as related issues in the Roadmap added
Updated by Philippe Cloutier over 3 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?
Updated by Sven Schuchmann over 3 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,
Sven
Updated by Go MAEDA about 3 years 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.
Updated by Go MAEDA about 3 years ago
- Related to Feature #2096: Custom fields referencing system tables (users and versions) added