Feature #9851
openEqualize the way how available shared versions are differentiated in target version drop-downs
0%
Description
I'd suggest to equalize the way how available shared versions are differentiated in target version drop-downs since they differ between issues/new and issues/index. See the following screenshots:
issues/new | |
issues/index |
I'm happy with either one as long as long as we're presenting a consistent UI.
Files
Related issues
Updated by Mischa The Evil almost 13 years ago
- Subject changed from Equalize the way how available shared versions are differenciated in target version drop-downs to Equalize the way how available shared versions are differentiated in target version drop-downs
- Description updated (diff)
Fixing ugly typo.
Updated by Etienne Massip over 12 years ago
- Target version set to Candidate for next minor release
Updated by Mischa The Evil over 11 years ago
- Has duplicate Feature #14449: Versions custom field format added
Updated by Mischa The Evil over 11 years ago
- Description updated (diff)
- Placed screenshots in table to seperate them better, and reordered them;
- Changed "constant UI" to "consistent UI".
Updated by Toshi MARUYAMA over 9 years ago
- Related to Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name added
Updated by Mischa The Evil almost 8 years ago
- Related to deleted (Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name)
Updated by Mischa The Evil almost 8 years ago
- Related to Feature #15902: Custom Field - Version - Combo list to be grouped by projects.. added
Updated by Edgars Batna almost 7 years ago
Make all version fields be presented similarly to the Target Version field (grouped by project name).
Also, take into account that the project name alone does not say much, if the project is in hierarchy with other, similarly named projects. Parent project names should be prepended to the project name.
You can test this and see that version management is impossible in Redmine once there are multiple hierarchy levels and trees.
Updated by Greg Burri over 6 years ago
I just tested this case with the 3.4.4 version of Redmine and it doesn't seem fixed. Custom fields displayed as a list with the Version format aren't prefixed with the project name when issue is edited so you can't distinguish between two versions having the same name but owned by different projects.
Updated by flabb17 _ over 5 years ago
+1
Same situation as describe by Gred Burri :
See #28865
Updated by Bernhard Rohloff over 5 years ago
- Related to Defect #28865: Group items by project in version type custom fields added
Updated by Stephane Poss over 1 year ago
As a work around for everyone passing by looking for a 'solution': here is an improvement. In app/models/version.rb
, add a to_s_with_project_status
method with content
def to_s_with_project_status "#{project} - #{name} - #{status}" end
And in
lib/redmine/field_format.rb
, find the class VersionFormat
, and change the possible_values_options
to def possible_values_options(custom_field, object=nil) possible_values_records(custom_field, object).sort.collect do |v| [v.to_s_with_project_status, v.id.to_s] end end
This will prefix the version in the list with the project name and postfix with the status. It's not ideal, but could help.