Why have some service desk statuses no status category?

[Peter Kaiser _Admin_]

If I create a service desk project some of the statuses that are created have no category.

This causes some of our filters to display service desk issues in such states where they are not expected or worse to not display them where they are expected.

I found discussions about the problem that it is impossible to set a state category to nothing with the UI and this can only be done in the database. But what I didn't found out is WHY those states have no category.

So, What should the states without category represent? Why don't they have one (for example why has "closed" not the category "done")? Is this a bug? How are we expected to use this "fourth" category? What should it mean that a status has no category?

[Yoni Az]

Looks like there was no intent to introduce a categoryless state, it was just a bug. The bug was resolved in JSCLOUD-9209 so any new service desk projects created after that bug was resolved have "Waiting for Support" and "Waiting for Customer" categorized as "TO DO".

As far as the impact of changing your legacy statuses to the "TO DO" category, seems pretty clear there is none. The helpdesk article on how to change them says:

> it will not cause any further issues other than changing the color of some status lozenges

And I opened a support ticket just to be sure and got confirmation of the same.

[Jack Brickey]

I'm on cloud these days which does not actually have the No Category but do recall server did. In cloud, if you do not change it default to "To Do".

Question - in Server, when you create a new status does it default to No Category? I assume so. If indeed that is the case I would say this is because when admins create new statuses the SW cannot interpret proper category. It does not interpret language and guess at the proper state. It would seem to me that it should force you to select a status other than No Category when creating a status as I think leaving in that state is a bad idea. It just was not developed that way. Of course this is simply my educated guess.

[Peter Kaiser _Admin_]

As you can read in the knowledge base article mentioned in the answer above it is also on server not possible to create states with "(No Category)" by UI. It has to be done directly in the database.

The article explains how to do it. But it does not explain, why it was done in the service desk templates by the developers and why I should want to create such states.

I just wanted to know why the developer of the templates did create some states with "(No Category)" (however how they did it). It seems not be possible to do it accidentially. So there should be a reason they did it.

I want to know if I should leave it as it is (and for what purpose) or if I should change the category of the states to what I think would be logical.

[Jack Brickey]

Ah I see. If you don't get a suitable answer here you might try commenting this the issue mentioned in the article or reaching out to Atlassian directly for an answer. 

Atlassian Support

[Peter Kaiser _Admin_]

Good suggestion. I gave a feedback to the article. :-)

[Kian Stack Mumo Systems]

Atlassian has a knowledge base article on this. It's not a big deal to change them if you want them to occupy a specific category. I've seen people change them because they were having issues filtering for "in progress" issues.

[Peter Kaiser _Admin_]

Yes, I know this article. But it just tells us how you can set a category back to "(No Category)" if you changed it to something other.

What I would like to know is WHY some states have no state category (even though some of them obviously represent "in progress" or "done" states) in the first place.

What did the developers of service desk intend us to do with this categoryless states? What did the intend with the introduction of the "(No Category)" pseudo additional fourth category?