Feature #9851
open
Equalize the way how available shared versions are differentiated in target version drop-downs
Added by Mischa The Evil almost 13 years ago.
Updated over 1 year ago.
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
- 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)
- Target version set to Candidate for next minor release
- Description updated (diff)
Fixed description:
- Placed screenshots in table to seperate them better, and reordered them;
- Changed "constant UI" to "consistent UI".
- Related to Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name added
- Related to deleted (Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name)
- Related to Feature #15902: Custom Field - Version - Combo list to be grouped by projects.. added
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.
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.
+1
Same situation as describe by Gred Burri :
See #28865
- Related to Defect #28865: Group items by project in version type custom fields added
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.
Also available in: Atom
PDF