Make a global category filter available from issues list at All Issues level
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.
#2 Updated by Gerry Hawkins over 11 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.
#4 Updated by Etienne Massip over 11 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.
#5 Updated by Gerry Hawkins over 11 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.
#8 Updated by Bernd Worsch over 8 years ago
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.
#18 Updated by Yuuki NARA about 4 years ago
I agree with following opinion.
I added a category inheritance function to Redmine 3.4.6 and released it to GitHub repository.
Category inheritance function will resolve this issue.
I think #5358 is related to this issue.