Feature #8192

Make a global category filter available from issues list at All Issues level

Added by Gerry Hawkins about 9 years ago. Updated over 1 year ago.

Status:NewStart date:2011-04-19
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues filter
Target version:-
Resolution:

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

Related to Redmine - Feature #5576: Have Category searches work for subprojects New 2010-05-23
Related to Redmine - Feature #6793: Report for issues with no category for all projects New 2010-11-02
Related to Redmine - Defect #23198: Group by Category does not group across projects New
Related to Redmine - Defect #26023: Category filter only shows categories of current project New

History

#1 Updated by Etienne Massip about 9 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.

#2 Updated by Gerry Hawkins about 9 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.

#3 Updated by Etienne Massip about 9 years ago

  • Tracker changed from Defect to Feature
  • Status changed from Reopened to New

#4 Updated by Etienne Massip about 9 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 about 9 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

#6 Updated by St├ęphane Gourichon almost 9 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,

#7 Updated by Najib Mestaoui about 6 years ago

+15 here
our company uses redmine, and we need this feature because we have the same categories (repeated) for all projects.

#8 Updated by Bernd Worsch about 6 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.

#9 Updated by Toshi MARUYAMA about 6 years ago

  • Resolution deleted (Wont fix)

#10 Updated by Joel Collins over 5 years ago

+1... This feature would be a big benefit to us.

#11 Updated by Christian Baus almost 5 years ago

+1 we need this too :|

#12 Updated by Toshi MARUYAMA about 4 years ago

  • Related to Defect #23198: Group by Category does not group across projects added

#13 Updated by Toshi MARUYAMA about 4 years ago

  • Category changed from Issues to Issues filter

#14 Updated by @ go2null about 4 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.

#15 Updated by JW Fuchs almost 4 years ago

+1

#17 Updated by Toshi MARUYAMA about 3 years ago

  • Related to Defect #26023: Category filter only shows categories of current project added

#18 Updated by Yuuki NARA over 1 year 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.

Also available in: Atom PDF