Because categories are tied to a particular project and there is no cross project categories list.

Thus, this is not a defect.
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
+1

Just hit that problem again. We'll be using a custom field instead, but a custom field does not do auto-assign.

Regards,
--------------------------------------------------------------------------------
+15 here
our company uses redmine, and we need this feature because we have the same categories (repeated) for all projects.
--------------------------------------------------------------------------------
+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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+1... This feature would be a big benefit to us.
--------------------------------------------------------------------------------
+1 we need this too :|
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
How about changing Issue Categories in the back-end to be a type of Version?
This way, they can be "shared":/projects/redmine/wiki/RedmineProjectSettings#Versions like Versions.

This should (would?) address all concerns.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+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.

--------------------------------------------------------------------------------

relates,New,5576,Have Category searches work for subprojects
relates,New,6793,Report for issues with no category for all projects
relates,New,23198,Group by Category does not group across projects
relates,New,26023,Category filter only shows categories of current project