Feature #9851
Equalize the way how available shared versions are differentiated in target version drop-downs
Status: | New | Start date: | ||
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | UI | |||
Target version: | Candidate for next minor release | |||
Resolution: |
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.
Related issues
History
#1
Updated by Mischa The Evil about 11 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.
#2
Updated by Etienne Massip over 10 years ago
- Target version set to Candidate for next minor release
#3
Updated by Mischa The Evil over 9 years ago
- Duplicated by Feature #14449: Versions custom field format added
#4
Updated by Mischa The Evil over 9 years ago
- Description updated (diff)
- Placed screenshots in table to seperate them better, and reordered them;
- Changed "constant UI" to "consistent UI".
#5
Updated by Toshi MARUYAMA over 7 years ago
- Related to Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name added
#6
Updated by Alexis Parent over 7 years ago
+1
#7
Updated by Christophe Portier about 7 years ago
+1
#8
Updated by Mischa The Evil about 6 years ago
- Related to deleted (Feature #19965: values of custom fileds of version type should be prefixed with or grouped by project name)
#9
Updated by Mischa The Evil almost 6 years ago
- Related to Feature #15902: Custom Field - Version - Combo list to be grouped by projects.. added
#10
Updated by Edgars Batna about 5 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.
#11
Updated by Greg Burri over 4 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.
#12
Updated by flabb17 _ over 3 years ago
+1
Same situation as describe by Gred Burri :
See #28865
#13
Updated by Bernhard Rohloff over 3 years ago
- Related to Defect #28865: Group items by project in version type custom fields added