Feature #9850
closedDifferentiate shared versions in version-format custom field drop-downs by prepending its project name
0%
Description
Like the subject already implies, I'd suggest to differentiate available shared versions in version-format custom field drop-downs by prepending its project name like it is already done for the target version attribute drop-downs. This way we can (also) distinct the versions from eachother whenever there are duplicates.
Some screenshots of what I'm proposing:
This is how it is now:
This is how it could look like (so we can distict the both 1.0
's)
Files
Related issues
Updated by Mischa The Evil almost 13 years ago
- Subject changed from Differenciate available shared versions in version-format custom field drop-downs by prepending its project name to Differentiate available shared versions in version-format custom field drop-downs by prepending its project name
- Description updated (diff)
Fixing ugly typos.
Updated by Maher Gamal over 12 years ago
Can we have this in an upcoming minor version ?
Updated by Maher Gamal over 12 years ago
The duplicate #10926 was marked as Candidate for the next minor version, can we mark this one as well to have it scheduled.
Updated by Etienne Massip over 12 years ago
- Target version set to Candidate for next minor release
Updated by Mischa The Evil almost 12 years ago
Simple patch could work. In source:/trunk/app/models/custom_field.rb@11275#L99 change:
- obj.project.shared_versions.sort.collect {|u| [u.to_s, u.id.to_s]}
+ obj.project.shared_versions.sort.collect {|u| ["#{u.project.to_s} - #{u.to_s}", u.id.to_s]}
to prepend "{project name} -
" before the "{version name}
".
This makes it possible to differentiate shared versions in version format custom field drop-downs.
Updated by Mischa The Evil almost 12 years ago
Note: the patch in note-7 does not prepend project names to custom field values in the custom field column on the issue list. This is the same behavior as currently implemented for the target version column. It might be better to change this also for (at least, shared) versions to distinct versions from other projects from current project versions.
Such should follow a fix for this issue first, so it will be better to open a new issue for that. Also #9851 needs to be taken into account since it is related in sense of how target-versions are displayed throughout the Redmine UI (now thinking of version#x
links, roadmap, version views etc. also).
Updated by Mischa The Evil almost 12 years ago
Mischa The Evil wrote:
Note: the patch in note-7 does not prepend project names to custom field values in the custom field column on the issue list. This is the same behavior as currently implemented for the target version column. It might be better to change this also for (at least, shared) versions to distinct versions from other projects from current project versions.
[...] Also #9851 needs to be taken into account since it is related in sense of how target-versions are displayed throughout the Redmine UI (now thinking ofversion#x
links, roadmap, version views etc. also).
Follow-up on #9850-8 [note-8], extracted from (duplicate) issue #10926-5 [note-5]:
Actually, the project name is already prepended to shared versions displayed on the Roadmap view with or without using theSubprojects
selection in the right side-bar. This also applies to both the project- and global Gantt views but specifically not for:
- the project Calendar view (since shared versions aren't displayed there anyways);
- the Version view (since versions are always tied to a single project anyway);
- the project- and global Issue list view columns and finally, I think,
- the Redmine version links.
Despite all the above: this issue is specifically about version-format custom field values and not the target versions.
Tested on Redmine 2.1.x / *.m.redmine.org.
Updated by Mischa The Evil over 11 years ago
- Related to Feature #14449: Versions custom field format added
Updated by Mischa The Evil over 11 years ago
- Related to deleted (Feature #14449: Versions custom field format )
Updated by Mischa The Evil over 11 years ago
- Has duplicate Feature #14449: Versions custom field format added
Updated by Maicon Zucco over 10 years ago
Hi,
How I change this in 2.5.1 version?
Thanks.
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 Maicon Zucco almost 9 years ago
I found a way to change on 2.5.3:
--- from_file
+++ lib/redmine/field_format.rb
@@ -690,7 +690,8 @@
scope = scope.where(:status => statuses.map(&:to_s))
end
end
- scope.sort.collect {|u| [u.to_s, u.id.to_s]}
+ scope.sort_by! {|u| ["#{u.project.to_s} - #{u.to_s}", u.id.to_s]}
+ scope.collect {|u| ["#{u.project.to_s} - #{u.to_s}", u.id.to_s]}
else
[]
end
Updated by Mischa The Evil almost 8 years ago
- Related to Feature #23265: Group versions by status in version custom field filter added
Updated by Mischa The Evil almost 8 years ago
- Status changed from New to Closed
- Target version deleted (
Candidate for next minor release)
Updated by Mischa The Evil over 7 years ago
- Subject changed from Differentiate available shared versions in version-format custom field drop-downs by prepending its project name to Differentiate shared versions in version-format custom field drop-downs by prepending its project name
- Target version set to 3.4.0
- Resolution set to Fixed
Setting target version to 3.4.0 because I think that this fixed issue should appear on the changelog, in order to let everyone know about this long-awaited improvement.
Updated by Edgars Batna almost 7 years ago
I'm on 3.4.3.stable and I don't see where this is fixed. If I add a Multiselection Dropdown Version Version Custom Field, then the list shows all sorts of Versions without Project names.
Could it be that it was only fixed for Filters and Roadmap? If that's the case, then all these Tickets might have been closed in haste.
Updated by Edgars Batna almost 7 years ago
P.S.
I'm talking about custom version fields when creating new tickets or versions.