Feature #8192
open
Make a global category filter available from issues list at All Issues level
Added by Gerry Hawkins over 13 years ago. Updated almost 6 years ago.
0%
Description
category is not available as a filer criteria when I am search issues from the view all issues page. It is displayed, and present in the grouping options, just not as a filter.
Related issues
Updated by Etienne Massip over 13 years ago
- Status changed from New to Closed
- Resolution set to Wont fix
Because categories are tied to a particular project and there is no cross project categories list.
Thus, this is not a defect.
Updated by Gerry Hawkins over 13 years ago
- Status changed from Closed to Reopened
So yet another cross project limitation. :-( One I don't agree with. Let me try to explain why I think this is a defect. Although as I edit this it is probably a defect in projects in general and this is just a specific case.
If this is to be closed, I would request to convert this to an open feature request instead.
From my user point of view category is a field that is present everywhere. It just doesn't have to have values that are available in every project, other than the default of 'none'. Why not just have a list of all the values that which is accessible for the top level?
I think that this limitation of projects is too great and drastically limits the potential of Redmine. I need to have a global view of all issues across all projects. And I need to the ability to filter on all fields all the time. Certainly limit the options in a field like category when I am in a specific project, but don't do it when I am looking across all projects.
Updated by Etienne Massip over 13 years ago
- Tracker changed from Defect to Feature
- Status changed from Reopened to New
Updated by Etienne Massip over 13 years ago
- Subject changed from category not available from issue filter list at All Issues level to Make a global category filter available from issues list at All Issues level
According to Gerry, the new filter should merge the projects lists.
The risk is to eventually get an incoherent list since a category item doesn't have the same meaning depending upon the project it belongs to.
Updated by Gerry Hawkins over 13 years ago
Thanks for the reopen and tracker change Etienne.
An incoherent list is indeed a risk of allowing a field to roll up from all projects and be used at the root level for all issues. But I think that risk is true of all fields. Indeed it can already happen within a project or at the all issues level with other fields. A user can already make many, or too many, target versions that are shared, or a global custom field that is a really long list that becomes unwieldy. I myself have created a target version that is "too long" and causes the formatting to look really bad.
But I think that at the all issues level it is not the tool's job to enforce this. Hopefully the user will have partitioned their values nicely. All I am saying is that by having an all issues level, effectively a root project from which all other projects inherit, I should be able to search for anything and filter by anything at that level.
I think the difference here is between having best practices and guidelines, and having the tool force and limit the work flow.
Thanks
Updated by Stéphane Gourichon about 13 years ago
+1
Just hit that problem again. We'll be using a custom field instead, but a custom field does not do auto-assign.
Regards,
Updated by Najib Mestaoui over 10 years ago
+15 here
our company uses redmine, and we need this feature because we have the same categories (repeated) for all projects.
Updated by Bernd Worsch over 10 years ago
+1
We use a category "security" to identify tickets tracking security defects or improvement ideas. This category is project global and may be used for all trackers. Turns out it is also kind of useless as we are not able to get all "security" Tickets accross projects.
Thinking about categories, i feel they should be global or have a scope. Project scope is a special case. It is useful to allow for tracker, projecttype (which at the moment is a custom field defined as a list here) or whatever as a scope.
Updated by Joel Collins almost 10 years ago
+1... This feature would be a big benefit to us.
Updated by
Updated by Toshi MARUYAMA over 8 years ago
- Related to Defect #23198: Group by Category does not group across projects added
Updated by Toshi MARUYAMA over 8 years ago
- Category changed from Issues to Issues filter
Updated by @ go2null over 8 years ago
How about changing Issue Categories in the back-end to be a type of Version?
This way, they can be shared like Versions.
This should (would?) address all concerns.
Updated by Anonymous 
Updated by
Updated by Toshi MARUYAMA over 7 years ago
- Related to Defect #26023: Category filter only shows categories of current project added
Updated by Yuuki NARA almost 6 years ago
+1
I agree with following opinion.
note-1,note-2,note-5,note-8,note-14
I added a category inheritance function to Redmine 3.4.6 and released it to GitHub repository.
Category inheritance function will resolve this issue.
http://www.redmine.org/issues/5358#note-98
I think #5358 is related to this issue.
Updated by Go MAEDA about 2 years ago
- Has duplicate Defect #37774: Can't filter the global query by Category added