ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Found in Version as a standard field (Feature #215)
Description
When opening issues, reporters should be able to pick the version that the issue is reported in, by choosing from a list of released versions of the software. Developers should be able to tag this further as affecting multiple versions of the released product. A patch is available at Redmine to implement this sorely needed and much neglected feature: http://www.redmine.org/issues/7443 with the original discussion at http://www.redmine.org/issues/1675
History
Updated by Ian Freeman at 2011-02-21 10:33 pm
Agreed, much needed.
Updated by Eric Davis at 2011-02-21 11:25 pm
I think this is two features in one:
- Allow a list custom field to have multiple items selected
- Allow a "Version" custom field
Updated by Ryan Thrash at 2011-02-24 05:15 am
Issue reporters would use a single custom field to serve the purpose of identifying where the issue currently occurs in their environment. The most critical two version-related items would be to have the released version in which the issue occurs identified, and the fixed-in version identified when the issue is resolved. The identified-in versions should populate dynamically from the released software version, not a custom enumeration.
I don't think tagging multiple affects versions is critical, but it would be nice to have.
Updated by Ian Freeman at 2011-02-24 07:36 am
I think if we're going to allow users to set "affects version(s)" to something, they should be allowed to add multiple versions. On the other hand, I don't know how useful the affected version list would be if the user doesn't also list which versions they've tested...
Updated by Ryan Thrash at 2011-02-24 02:42 pm
I don't think end-users/reporters should set the affects version at all.
Typically normal end users are running a single version of software, and won't take the time to install old versions and/or backtest. They should have a field to indicate the version they're using: Reported in ... Developers working tickets can test and verify and then indicate which versions it actually affects in another field: Affects
End users should never be able to touch the Affects field due to the likelihood of inaccuracy. Honestly, the functionality of dealing with Affects is optional in my opinion (but much desired and a good candidate for iterative improvement). Reported in can handle the most critical aspect of filing the report and is the most troubling bit because it's not a standard field today that automatically enumerates off the released versions.
More discussion from the mother project:
http://www.redmine.org/issues/685#note-22
Updated by Ryan Thrash at 2011-03-31 04:29 pm
Is this still up for consideration as part of the core distribution in a (hopefully soon) release?
Updated by Eric Davis at 2011-04-01 10:55 pm
Ryan Thrash wrote:
Is this still up for consideration as part of the core distribution
I think so (see my comment above).
in a (hopefully soon) release?
As soon as there is a patch or pull request submitted we can review it and include it into a release.
Updated by Ryan Thrash at 2011-04-02 01:35 pm
Would the patch at the Redmine project work? http://www.redmine.org/issues/7443 (and attached for convenience ... goes against redmine 1.1)
- File found-version-1.1.0.patch added
Updated by Eric Davis at 2011-04-03 11:24 pm
The patch is missing tests.
Updated by Ryan Thrash at 2011-04-03 11:26 pm
I'm not a Ruby dev, so unfortunately I won't be of any assistance on that front.