So here it is 10 years later and Atlassian still won't reconsider.  Atlassian has a long history of smugly substituting process for knowledge. 

Dave, this should be reconsidered. We have many tickets that are 'invalid,' and right now they are being tagged as 'done', which is extremely counterproductive. We should at least be able to add one custom category. 

It could be very useful to have another workflow category for status In test/In Review so we can see in recap progress bar of release page 4 colors:

Grey as to do

Blu as in progress

"new color" as in test/review

maintaining a standard approach of Atlassian

Adding more custom status categories may not be a good fix as it might affect the internal implementation of Jira features. But can we have custom groups or any other way to categorize the statuses? Since we have the option to build our own workflows with the custom status we can not put all these statuses into these 3 categories. When we make filters, status categories are becoming useless and it is very difficult to manage all the filters by adding or excluding individual statuses.

Totally agree with David. 

Dave you should consider it again - adding it helps build more effective JQLs using StatusCategory instead of Statues which helps build multi-project boards and dashboards. If needed, happy to provide you with detailed cases.

In our organization we have 5 different categories of tickets and it would be nice if we could have JIRA recognize that.

Planning/Analysis -> To Do (Backlog) -> In Progress -> In Review -> Done

Within those categories we have the following statuses:
Planning/Analysis
(New Idea -> Requirements Analysis -> Stakeholder Review -> Scheduled)

To Do (Backlog)

In Progress

In Review
(QA Review -> Code Complete -> Code Review -> Testing)

Done
(Ready For Release -> Released)

We currently make it work by utilizing multiple boards and manual labor to convert issue types etc... Other larger organization I am sure have other quality assurance processes that require more customization in this area.

Example of where it would be helpful. We use an addon BigGantt to help with the planning of tickets. BigGantt has two task colouring options, Status Category and Manual. I would like to have more that 3 colours, but the colour is assigned to the category and there are only three options. If I could add another category type I would be able to organize my work better.

So big up vote from me to have this configurability. 

This is very silly. It should be an out-of-the-box feature. 

You could all save yourself some time if you realized that Atlassian knows what is best for you. Quit trying to make your own workflow to support your business and only do it the way they say it should be done. That is why we pay them higher licensing fees each year for less and less features out of the box.

This should definitely not be "Closed" and ignored.  It really limits the usefulness of Jira and it's not something we as administrators can easily edit, because believe me, we would take it into our own hands.

@DaveMeyer

This would be a very useful feature. Especially thinking about "Failed" / "Rejected" / "On Hold" etc. which is none of the predefined status categories. It's not open anymore, nothing in progress and definitely not done!

So why Atlassian is so balky about this issue? I really do not understand because it would bring so much benefit to so many users.

For those adventurous enough, the code is in
jira-project/jira-components/jira-core/src/main/java/com/atlassian/jira/issue/status/category/StatusCategoryImpl.java

I was able to recompile a copy of this file using install.dir/external-source/build.xml and Ant in Jira 8.5.3
I had to download jsr305-3.0.2.jar to get it to compile.
That's one way to change colors but you are restricted to the ones already defined in
issue-status-plugin-2.0.2.jar

But from the source code I see the cautious comment:

        *
          Status Category Name is hardcoded here instead of taking from default i18n bundle because changing it would
          break existing JQL filters and requires an upgrade task and/or backward compatibility coded into
          StatusCategoryValidator and StatusCategoryClauseQueryFactory.
         */

This is downright shameful. It was bad enough when Atlassian ignored key features that thousands of users were begging for - now they are REMOVING features because they believe we don't need them. Of course, the Add-On vultures are happy to swoop in and provide this feature for an additional per/user cost. I believe Atlassian's days are numbered.

>Resolved 14/Jan/2015

>Still getting comments in late 2019, now early 2020

Atlassian, you need to rethink this. You have plenty of other adjustable knobs(Custom fields, anyone?) you give us and disable us from modifying the ones that you set into the system(Assignee? Epic Name? I could go on).

Let this be another one, clearly this is a desired feature.

+1 - I am used to seeing yellow as an in Test or Review indicator, I think Jira server 7.x.  But now that I am using Cloud, all I see is blue.  It is not helpful.  @Dave Meyer, please consider widening JIRA's color palette.  It's really impactful on communications to enable color usage.

Atlassian wants customers to use Jira and Confluence?  That sounds great.  I'd like a Lexus in my driveway and not have to work for a living, but the reality is money is a factor.  Using Confluence means having to buy a whole new application license.

Atlassian wants customers to use Jira and Confluence but the fact that Confluence has more Status color options is an imbalance that is impacting the user of the tools together. I have a client who is not happy that I cannot show a red status for data I pull from Jira into a Confluence page because it (red) does not appear in JIRA. This is a serious issue that has impact more than one client

Especially since clients do not want to buy another add on..

Yet another example of Jira not listening to 200+ admins..  You've lost my endorsement.  I never thought I'd say that about Jira.  Every time I look for something I need the response is "Try this workaround, won't fix, or some other garbage explanation as to why you won't do the work.  Whoever is designing your new UI is killing your previously loyal customer base.  And there are only 204 upvotes because you're blocking people from upvoting now that you've closed it.

My need : The mapping of blue, yellow, orange and green to "To Do", "In Progress", "Ready for QA" and "Done" 

For development teams, it helps to have a way of grouping some statuses into buckets that represent Development, Validation, User Acceptance, etc.  Having all these as In Progress makes it hard for us to get good info out.

I didn't like this new Jira UI experience, I need more color in the status 

There is one additional valid reason to ask for a single new category. If I want to measure flow efficiency (how much of the total duration of a piece of work has been spent queuing versus working) then I need to have workflow states marked as inactive/waiting/queueing (whatever word most makes sense). Right now, I recommend that people use "To Do" to represent all the waiting. However, I don't know what other metric/visualization that will mess up if that is meant to show the wait BEFORE the work has ever "started". Does this make sense? Can you please tell me what the consequences would be or if a new status would really be warranted?

could you reopen this issue?

the status categories still need.

that issue was not resolved

I just got the new JIRA update.  Among other things, you changed the "visual system", from the status colors from blue, yellow, green to gray, blue, green which seems like a step backwards.  The gadgets were not updated to match.  And the epics colors have radically changed, but the epic color picker are the old colors, so that is a bit odd.  Any way to override the new default status category colors?

How would you programmatically know, that an issue is done? Issues status can be configured and named in any language, so it has no meaning to software in general. A lot of admin do not properly maintain the workflows and often take over the default settings: the resolution is not always set although an issue is done. Currently, the status category is the only available indicator for issues being done as the key="done" of a status category is fix and cannot be modified by any user.

Why would I like to know, if an issue is done? Well, to automatically calculate the progress of e.g. a sprint or portfolio, that's important to count the number of story points of issues being done divided by the number of story points of all related issues!

Hi George, thanks for sharing the plugin, just installed it for a test run.

Hi all,

I understand the reasons why Atlassian is reluctant to add more status categories. I also understand though why many users would welcome them.

I would like to recommend the Status Color plugin. It does not add more categories but it eases the pain a bit. It allows to color issues based on their status in filters, dashboards and agile boards. It is free, most of all. Maybe it helps you as it did us.

http://www.lewe.com/jira-statuscolor-plugin/

+1 to Steven's last comment. Even I (years ago) complained about this feature on this very ticket (and still get updates on it to this day) but I definitely see why categories are utilized the way they are now. If you need full resource planning, JIRA isn't going to cover it. The core product is for Project management. You don't need to buy Tempo AND Structure (also ouch that would be a hassle to maintain) as just purchasing Portfolio should complete your requirements for a full resource utilization suite.

Blocked and canceled are not states in a typical lifecycle of a business process.

"This statusCategory feature request itself is so hilarious to me. Every single person here who is asking for a "blocked" or "canceled" category has seemingly zero idea of how business process design works."

A rather arrogant statement. IMO. Does no one else know how to be successful in the workplace?

JIRA is OK, but it seems to be designed by people that refuse to change their thinking (IMO). Things change over time. Technology needs to adapt. JIRA says "JIRA Software lets teams work how they like." If they really did this, some teams would be allowed to add more categories to statuses, since that is how some teams want to operate.

My team would like to work in a certain way. Unfortunately, JIRA doesn't truly allow that.

Yes, Now I need to buy another product Portfolio for JIRA. Wow! 

Whats funny about having different status category? Include one status and will it destroy report ability? 

I have nothing against JIRA. It was not my choice to buy JIRA software it was there before I joined the project. But if I am given a chance Ill change it and am working towards it.

Cheers!

Well now I'm just confused. Your original comment seems out of place. JIRA doesn't offer or advertise 'resource capacity planning' and never has. Atlassian's own offering is that of the Portfolio for JIRA add-on which is intentionally the resource-capacity planning tool. Portfolio for JIRA also offers hierarchy Anything -> Epic -> Story -> Sub-Task. It seems to me that what you really want is JIRA Software + Portfolio for JIRA.

So to me, it seems like you're complaining that you didn't buy the right product. JIRA isn't bait-and-switching you: Buy the tools that give you the capabilities you want. JIRA offers a great product at a great price point, in my opinion.

This statusCategory feature request itself is so hilarious to me. Every single person here who is asking for a "blocked" or "canceled" category has seemingly zero idea of how business process design works. You do not want more statusCategories. Process lifecycle is either not started, actively in progress, or completed in some fashion. You are supposed to use Resolution to stat what happened to an issue, not a status.

Using a Status for every possible reportable condition destroys reportability, makes navigating a workflow difficult and confusing.

@Steven Behnke 

Well I want to keep track of resource capacity every sprint... I would need to add a plugin tempo. 

I need to view structure of issues  Theme>Epics>Features>Userstory>Tasks ... I would need to add a plugin structure

I just want to add category "blocked", guess what there can only be in three categories  "To Do", "In Progress", and "Done". 

I am new to JIRA and after using Rally, I feel JIRA needs a lot of plugins.

vasavi.kakkat, care to add any detail about what "basic features" jira does not include?

I have used Rally extensively. JIRA just does not support basic features and needs lot of plugins. Such a pain!

+1

These categories are vague to the point of being useless.  In Progress and Done are nice but what about in testing?  That's neither.  That happens AFTER the work is done.  What about Closed, which is after the work is done and after it's tested? 

This very task could be DECLINED not CLOSED

It's really important for many teams to separate tasks that were really done and therefore closed or skipped for some reason ones

tewr0512366717 I don't using red for Closed since this is essentially an issue that is done. If an issue was not done at all, its not necessarily a bad (usually associated with red) thing as the issue would only be Closed (the Resolution dictating its reason) if it were justified. However, I would like to see a category Called Blocked with either orange or red.

Closed status should have a RED Status Category. If it's closed it means the story/task may not have been done at all (e.g., perhaps there was no need for it).

We definitely need a RED Status Category for BLOCKED in JIRA.

The idea is to mark issue status in red, i.e. new status category of BLOCKED, in case, a prerequisite to work on the issue, is not given.

An example: The infrastructure team is not able to provide a required data base system to me yet, where I can reproduce and fix an application bug. Therefore, it is impossible to me to solve the issue even if I want to. In that case, we need JIRA to show issue status in red, signalizing, something is impeding the progress on that Issue, i.e. special attention is needed.

Please, F1! Solve it! Thank you.

Great.... So it takes all of a week for some frustrated, keen and capable customers to reasonably adequately address an issue that has been open for over two years. Now the issue becomes one of: compatibility with Jira cloud, and long-term support.

Atlassian are not off the hook. They really need to get such functions supported in the core framework. I don't understand why these heavily-requested and obvious features/limitations are not addressed by Atlassian and they rely on their customer base to solve their problems through variously-supported or in some cases paid plugins. Lazy much? If Atlassian are not going to maintain Jira to the required standard, then how about open-sourcing Jira Core and let us all collab on it!

Great job George! Of course, now all that's left for me is to get off my $Unable to render embedded object: File (% and upgrade JIRA to 7 (it's been on my list, but now you've moved it up). Thanks for the amazing turn around time) not found.

Yeah! @George Lewe you rocks!

@David Rhoderick: Ok, you got us hooked. The JIRA 7 version of the JIRA Statuscolor plugin now supports Agile Boards as well. Get it here: http://www.lewe.com/?p=683

@David Rhoderick: We were thinking about extending the JIRA Statuscolor plugin to Agile boards too but we are just too busy right now. But it's on the radar there as a little dot...

The JIRA Statuscolor plugin is free as well and configurable. Since it uses a different approach, you can even combine it with Raul's.
And yes, unfortunately Cloud users cannot install those plugins.

And for those of us on Atlasssian Cloud (Jira Cloud): Boo hoo!

Because is the first version! In the next weeks I will work to configure them! Thankssss!

And free too. raul.pelaez is the hero we need. Curious why the colored statuses plugin is not configurable?

Yes thanks a lot, this is fantastic! Great work!

I hate to ask for anything more but I feel it's going to happen anyways: Is there any way to get the colors to show up on an Agile board? At the very least, in a sprint? I tried to add the field to the card layout but it didn't change the background color.

~Dave

@David Rhoderick: All good now. Files fixed at Lewe.com

I would but I need customizable status colors.

BTW ... You can use my plugin (new since today)
https://marketplace.atlassian.com/plugins/com.rauliki.NewStatusColors/server/overview

I downloaded version 1.0.5.1 following your link. It downloads completely, then I tried to unzip on Mac OS X using either the built-in tool or through Terminal and I get a cpgz-zip file cycle. Is the file corrupt?

*Edit*

I have also tried with the Unarchiver and by changing the extension to .rar or .sit.

Reducing status categories to only three is a valid approach to address simplicity, for example in Agile boards. I understand that there is a techincal need for it.

What this approach is not able to address though is the simple but obviously pressing need of many users to visually distinguish status. And I am not talking about offering a few more categories, I am talking about the possibility to give each and every status its own color. So indeed, this issue is not about adding more status categories but to provide coloring options for status.

Atlassian, maybe you can find a way to implement such a feature independently from maintaining your three status categories. A simple but effective approach could be the following.

What you see in the screenshot (jst-jira7-gadget.png) is the work of a plugin that offers that option for filter result displays (also works in dashboard gadgets). In my opinion, this plugin will ease the pain for most commenters here. It is a free open source plugin that is not maintained anymore by its original developer. We have patched it to be compatible with JIRA 7. Read more about it and download it here:
http://www.lewe.com/?p=683

I think the problem, is that statuses used to function like Priorities still do: they allowed custom icons and custom lozenge colors. Our use case is probably very different from most others: we don't do software development, we do lecture production for online courses. Isn't that business development - making software that works for more people in different ways - making it somewhat flexible for different users? I've tried to lay out what our primary issues are with lots of colorful pictures here:

https://docs.google.com/document/d/1oE7iStcwMgtdDKgM4LqdWsSeu7jNTGEwANNImUS-yFc/edit?usp=sharing'

You'll see we had a nicely evolved set of icons that showed both color and numbered stages in our 14-15 step production process workflow. We've also duplicated these to Priorities, since in many cases, they work better. But the status changes Atlasssian have made have been too constrained and limit our ability to visually better see what is going on.

how that translates into defining the problem, or proposing solutions, I don't know exactly, but the main gist is to make

https://whatever.atlassian.net/secure/admin/*ViewStatuses*.jspa look and work more like it used to, or more like:

https://whatever.atlassian.net/secure/admin/*ViewPriorities*.jspa

thanks!

Attention all watchers of this issue. To try to make progress, i have followed Mark's request and created a new suggestion with a different solution at JRA-60386. Please vote and watch that issue if you agree that a change is needed. Hopefully this new solution will be more appealing to Atlassian and all JIRA users.

Mark-

If we do as you suggest and start creating issues for ALL the possible solutions to this problem, then how do you decide which one is the best possible solution? Right now you have a single issue that administrators and users are still finding due to delayed upgrades (in-house server) and expressing their frustration with this NEW feature to them. I was one of those people that by the time we upgraded to a JIRA version a year ago that had this new "functionality" this issue was already closed. However, if everyone starts creating their own solution issues to the problem, then you split apart all 204+ votes and 150+ watchers and counting onto multiple separate issues. Therefore, if you base your enhancements off of "votes" as Atlassian is so proud of doing, i would bet that none of the new solution issues would gather enough votes to get on your radar.

I do agree that there are other solutions to this problem than just adding more custom categories, and many of those solutions have been suggested in the previous 100+ comments. However, i think all the administrators and users that have voted and commented on this issue can agree that the current functionality of categories is NOT the correct solution to the end goal you are striving for.

Exactly, David.
The idea of the three fixed categories is based on the simplistic default JIRA workflow which is far off from our reality.

We have several workflows where tickets or epics undergo multiple stages until they are actually completely "finished", and there is no clear distinction between "TODO", "In Progress" and "Finished" in such workflows. It depends what is your part of the workflow. Example:
Customer Request > Evaluation (CEO) > Customer Requirement Analysis (PO) > Contract (Secretary) > Scheduling > Implementation + Documentation (Coders) > Review/Approval (PO/Customer) > Delivery > Invoice (Secretary) > Closed
... plus possibly a few other statuses like "Waiting for customer feedback" or "Frozen" which need special treatment.

Atlassian should avoid doing assumptions about workflows, especially since so far nobody has really explained why they were needed in the first place (given that previous versions of JIRA worked very well without categories).

Hi Mark,
I don't believe that anyone is necessarily suggesting a solution here. If you have taken the time to understand the problem and can propose an alternate solution then why don't you create such a ticket and link this to it? We would love Atlassian to take ownership of such issues if that's what it takes to see it actioned (I'm following some which have been open 10+ years).

Regarding your comment: "JIRA has a way to tell if the status is 'To Do', 'In Progress' or 'Done', and therefore treat these differently. This only works because it is a finite well-known list.."

You refer to "Agile"-like concepts that have been imposed on the Jira community which do not apply to every project, particularly those who just use Jira "Core" (as it's now referred to) in isolation should not necessarily be held to these static concepts. It almost sounds like you've never had to create a custom workflow...

What people administering more complex projects are asking for is a way to bucket up statuses into their own categories to make Jira more flexible and better fit their business needs. I don't think this is too much to ask.

If the statuses and categories could be iconed and coloured and searched for through JQL filtering, then I don't see that there would be any other impact to Jira's workings that precludes the idea that Jira admin's should be able to add new custom categories. Categories should have a configurable sort order. The necessary Jira functions and reporting should be built to adapt to this. Any other competitor task tracking product would have this capability, but often Atlassian seem blind to some pretty obvious requirements.

Just for consideration, before the notion of Status Categories was invented, the most important field in Jira was 'Resolution' which primarily drives Jira workings and reporting (open vs done). That was the only requirement imposed.

To those that are disappointed that this issue is closed as won't fix: you need to understand that the particular solution named in this issue is untenable.
Namely "Ability to add more categories to statuses".
Users can create arbitrary statuses, but the problem then is that JIRA has no understanding of the meaning of that status.
Enter status categories. Now when you create a custom status, JIRA has a way to tell if the status is 'To Do', 'In Progress' or 'Done', and therefore treat these differently.
This only works because it is a finite well-known list.
Perhaps we can expand that list by adding other well-known (hard-coded) values, but we can never let categories be customisable, because it defeats the whole purpose of them.

Now, reading the comments, it seems that some people don't like the limited set of colours used to render the statuses, others want to bring back icons for statuses.
"Ability to add more categories to statuses" is not going to happen, but it's not the only possible solution to those problems either.
If you care strongly about this, I suggest you raise a different issue.
One that suggests a different solution ... eg "let statuses override the default status category colour".
Or better yet raise an issue that describes the problem instead of describing just one of the possible concrete solutions.

This issue should be cloned, maybe set the summary to

Reconsider JRA-36241: Ability to add more categories to statuses

Sounds like that when I read statements like this one over and over again.

"Thanks for voting and commenting on this issue. Your input in the comments helps us understand how your teams work and what you're hoping to accomplish with JIRA. We have decided to close this specific request...I understand that our decision may be disappointing."

Well that's not quite fair. You put that in quotes, but I don't think Atlassian has ever said that.

The more I use Jira, the less I like it. Every single time I search for how to do certain things (since the interface of Jira Administration is a disaster) I come across a thread like this one. "We won't do that because we don't think it is necessary. Users aren't important."

Sigh.

We can add one more category "hidden" with: https://jirasupport.wordpress.com/2015/10/27/jira-trick-set-one-more-category-status-color-the-undefined-color-black-color/

Well there's a paid plugin for that sigh

+1

This is a big bummer. The colors should NOT be tied to some integral system. At the very least, they should allow only colors to be changed by users, while the statuses can stay the way Atlassian needs them. My "Won't Fix" items are in green, which looks absolutely ridiculous!

the Atlassian's overall visual system now shows six colors. Not sure why Atlassian is preferring to set a limit on something like this when it make no sense to limit to the three colors/categories. . . over 200 votes wasted.

One can only hope that Atlassian has a vested interest in their long term customers. However, as is evident from the responses (or lack there of) from Dave, they have no interest in listening to logic and following through with the best possible solutions. Instead they hide behind the "Agile" development process, so larger enhancements get started in smaller chunks, due to the need to fit them into Sprints. Then, the actual useful portion of the change instead of the pure cosmetic portion never gets fixed, and the enhancements get closed.

I sent 2 emails to Dave regarding this issue. The first was responded with useless fluff regarding their changes. Then, the second when i presented him with a concrete screenshot of how the status lozenges caused confusion and provided no value, i have not heard anything back.

This just goes to show that they will post their emails out to present the illusion that they will listen, when in reality they can ignore you just as easily through email as they do on their issue tracker.

And now I seem to be just talking to a wall and as the saying goes "Arguing on the Internet ... ". So I will end it with that as we all know that we can rant and rave all we want about this, but in the end Atlassian will just continue to do whatever makes them happy even though it serves no long term purpose.

Hi Adam Barylak,

> "If you are truly interested in the needs of your customers, and will possibly at some time change this functionality, then you should leave ...".
why do you think that atlassian has an interest on long term users.
With every major version you have to change yor workflows to fit to new jira funkctions.
If it is for the customer a bug then one get the answer "no, it's a feature".

As i understand Dave Meyer then you can not as you like it only with jira.
>Use the card colors based on JQL queries feature (documentation) to define your own colors for workflow states. I've created this suggestion in the JIRA Agile project to improve this in the future: GHS-11666
>Use JIRA Agile card layouts...
Well if everyone works with agile maybe it was possible to live with 3 colurs if not then you have to buy agile.

Closed, unassigned and impossible to vote (other questionable design decision)...

Time to use old email to nag persuade product management, to reopen it.

Why does Atlassian's branding excuse a feature that so many users request? How come there's even a red "REMOVED" 'lozenge' on the standards doc but there can't be one in the app?

I have the perfect screenshot that i would love to attach to this issue which clearly shows the uselessness of these limited colors. It is a screenshot of linked issues. We use JIRA as a ticketing system as well as a test case management system as well as many other uses. And only 30% of our workflows fit into the nice blue yellow green categories. So, on the screenshot i have tests that were run, and a few were Passed and a few were Failed, yet, they are all Green status lozenges. How is the normal user supposed to work with completely useless feedback like this? They all look green as in good to go, but they are FAILED. Which is also all in caps, so your mind doesn't immediately recognized the text and it takes longer to determine the actual status. We used to have a Red X in the status image for failed, and a green checkmark for passed. This was an amazing way to easily see the overall health of the tests on an issue. Now, the status "categories" are completely useless.

Dave, i will email you directly the screenshot of the useless categories so that you can see for yourself how normal companies use JIRA and see that 3 categories is not sufficient for anyone.

Please bring back the status images, they were so much more useful.

Adam

Dave-

One of the problems I think we all have with the handling of this issue is the timing of closing this issue. This is because since you have closed it, it no longer is able to accept votes, therefore eliminating people from expressing their interest in this "Re-Enhancement" in a quantifiable manor. If you are truly interested in the needs of your customers, and will possibly at some time change this functionality, then you should leave the issue open in order to allow votes and quantify the need for this "Re-Enhancement".

I for one didn't even know of this change until last month when we started planning and testing our upgrade, and just found this issue yesterday far after it was closed. Therefore, I feel that my vote and future companies' administrator votes will be completely ignored because nothing is recorded in a quantifiable way for you to asses later.

On the other side, regarding your comment about "So when we choose to limit functionality", this means that you are aware that you have removed pre-existing functionality, but at what cost? The vast majority of JIRA users will never look at the "Releases tab" because they are only concerned with their work items and what is scheduled for them to do, not how the overall project is progressing. Therefore, instead of removing functionality and making it tougher for the vast majority of JIRA users to identify issues via status, you should have been figuring out a way to enhance this functionality to include an additional way of categorizing statuses on the project level. This is because statuses can be used for different reasons per workflow, so what would happen if one workflow uses a status as a complete status, but then another workflow for a different project uses that status as an In Progress status? Therefore, one of the projects categorization will be incorrect. The categories should be done at the workflow level at the minimum, or configured at the project level. These changes should really be thought through a lot more before removing functionality and painting yourself into a corner where there are limited ways out.

Please re-asses this "Un-Enhancement" of the lozenges and categories, and please at the very minimum re-open this "Re-Enhancement" to bring back the flexibility that was abruptly removed.

Thanks.

Adam

Hi everyone,

There have been a number of comments on this issue recently, so I thought I would comment.

First, it is wholly inaccurate that Atlassian does not see or is ignoring comments on suggestions on jira.atlassian.com. Personally, I am watching the vast majority of the top 200 suggestions on JAC and I read every single comment. However, it's not feasible for us to engage with every single comment. Usually, when a JIRA product manager comments, it is to do one of three things that will provide value for everyone watching the suggestion:

1. Provide an update on the status of an issue.
2. Get more information so we have a better understanding of what customers are looking for.
3. Clear up misinformation or answer a question.

JIRA is intentionally designed to be as flexible as possible. The degree to which you can customize JIRA's fields, workflows, screens, and issues is, without a doubt, one of JIRA's biggest strengths as a product. We believe that it's important to let a team customize the product around their needs. And if the level of customization isn't enough, we have almost a thousand public add-ons on the Atlassian Marketplace and extensive APIs, and we've invested tremendously to ensure you can extend JIRA whether you run it on your own server or use a JIRA Cloud instance that we host.

So when we choose to limit flexibility, in this case, it's because we have a really compelling reason to do so. In this case, having a discrete set of status categories allows us to build features that we believe offer a lot of value to teams in a reliable, performant way, like the new Releases tab.

We absolutely recognize that we won't always be able to make a decision that pleases everybody, every time. And our plans and reasoning may actually change in the future; however, we believe it's important to communicate our current position on this issue clearly, which is why this issue is closed. JAC is the primary channel for us to communicate about specific issues, and we absolutely do not ignore it.

As always, you can email me directly: dmeyer (at) atlassian (dot) com

Regards,
Dave Meyer
Product Manager, JIRA Platform

This ticket is even more painful to watch being ignored if you imagine all the projects with workflows that has nothing to do with DevOps.

204 votes and Atlassian closes it as "Won't fix". Very strange approach to the customer feedback

Please reconsider this change. It's nonsensical.

I also would find this very useful and echo all of the sentiments above.

I just looked at my dashboard in the new version again since we are planning the upgrade now, and it looks ridiculous, the status field is useless to show on a dashboard. I have 10 filter gadgets on the dashboard and every single issue in every gadget is a yellow status lozenge. That tells me nothing when i'm looking at my work items.

This has to be changed, because we are now going to have to implement more custom fields and more scripts and more plugins in order to find a workaround for this stupid lozenge color that doesn't tell us anything anymore because we only get 3 colors.

Speaking as an Administrator of JIRA, it is the Administrators job to control the different icons for statuses (colors if we are able to create more), and therefore still make them useful to the users. JIRA is NOT a high level executive view of projects, it is a workers tool to categorize their work and therefore EVERY field is important, and now it will take extra time when looking at filters to determine which status the issues are in, where previously it was just a glance you could tell by the icons.

Atlassian really needs to re-asses their priorities and stop hamstringing the users that use their product. If you loose the support of the lowest worker, then they won't use the product correctly, therefore negating the affect of reports for the higher level execs and managers. You have to satisfy the people doing the work in the product before you can get valuable reports. Garbage in Garbage out.

Atlassian better start making some better improvements for the users or we will be looking for a new product before the next renewal.

Please re-open this issue, for those of us that are just upgrading JIRA to a version with these new lozenges haven't even had a chance to vote on this issue or provide their input. Not to mention the ones that still haven't upgraded yet and have no current plans. This is ridiculous.

A status is be nature a more detailed version of "To Do", "In Progress", and "Done" that is used in the JIRA Agile product. At least in JIRA Agile they have the ability to Flag issues. This would be like a different color for a "lozenge" such as Red or Orange.

There are thousands of different ways to use JIRA and the Issue Icons in the past have worked great, but now you remove functionality by dumbing down statuses to 3 colors. You may as well delete everyone's custom statuses and just give them a Green, Yellow, and Blue status. Then everyone can just use the green yellow or blue status in their workflows, and we only need 1 workflow and 1 use case for JIRA and we can then remove half our user base and reduce our license therefore reducing the amount of money we send a company that seems to think removing functionality and limiting innovation and limiting the uses of their product is a good thing.

Just mark this one up as to another reason why we may not renew our license and will look for more flexible and useful solutions in the future.

I'd also like to add my support for this. A Red "Fail" would be a HUGE help for me in multiple different circumstances, and is a necessary (albeit negative) part of the Product Development cycle.

Hi,

i would like to vote also for this issue.
I hope you think over the decision to "won't fix".

I need the ability not to delete issues but one would of course delete issues.
For this requirement i made a new status "mark for deletion".
With only 3 categories it feels bad. Delete is not done it should be aout of the scope of everything.

Please add the ability to have some more categories.

Thanks,
michael

Hi Team,

I would like to Vote for this feature, Like to know is there any consideration in Re-look at the decision of Won't Fix?

Thanks
Arasu.b

I also need a red status

I feel that there is benefit to being able to customise the Status Categories, however, given the amount of feedback and the value of the Release Hub dashboard, how about considering adding a few more generic options into the system by default?

Adding a QA (or testing, or whatever it would be called) status onto the Release Hub would be hugely beneficial, not just for our thousands of users, but I'm sure many many many other installations.

1. To Do
2. In Progress
3. QA (orange)
4. Done

Given the drive to enable people to develop higher quality products, not including a QA option in a release hub seems very short-sighted.

We use JIRA on demand and have found that the recent navigation change has replaced the old "issues by status" release summary with a much more minimal release summary which uses "issues by category".

This change has significantly increased the profile of JIRA's issue categories (green="Done" yellow="In Progress" blue="To Do"). It means that for JIRA users such as us who've been productively using a custom workflow for years now cannot readily work the way we have worked.

For example I now need to write a query on the issue navigator to select the resolved issues in my latest snapshot version. I can't quickly go via the release summary page and click on "Resolved". Because now the release summary page gives me "Done" which includes "Closed". Of course I can write a query, but for us this is a process which will be done when a manual build is done and we need that to be a task someone with limited query skills can execute.

The fact that this change has been made in conjunction with the above decision not to support customisation of the now-important issue categories has put my team into a position where our tools are actively wasting our time and working against us. And that's not a position I think anyone wants us to be in.

Not everyone fits in with Atlassian's "Overall visual system". We want to use the tool to complement the way we need to work. JIRA has until now been impressively able to meet that challenging requirement. But here I feel as if someone else's concept is being forced on us and that we've been given no option to continue to do things our way. In this case it's really nothing to do with visuals either. We use issue statuses extensively in our process and our statuses on our boards and ideally on our release summaries. And in our use, resolved is not done and we can't map all our statuses to just 3 fixed categories.

So it's not about colours here. It's about how we work and what resources we can use to do what tasks.

Our blockage in this case could be cleared if the release summary page included the old issues by state count below this un-customisable and fairly useless (to us) new release summary view with the categories that don't especially apply. We just need something to click to quickly get to a bunch of issues in a common state in a version.

And I know I can create a filter for that. But I don't want to have to create and share a new filter every time that version is released because this adds unwanted paperwork to what is already a reasonably involved multi-product release process.

Meanwhile, categories would be really really useful to us if we could have maybe 5 of them instead of just 3. And if we could rename them. If mappings of issues to categories became the default lanes on new boards, and were how release summaries presented...well that would make these categories valuable, even to people with customised workflow.

So it is unfortunate to read that a decision has been taken to set these categories in stone.
+1 from us to that decision being a problem.

This is an idiotic decision that definitely f's the customer.

Very disappointed. None of the workarounds help...need to differentiate between in-progress statuses on a dashboard and NOT in Agile or in the Issue Navigator.

I can't believe how topical this is. After using Jira for a couple of years, I tried TODAY to set a new status category/Colour
This would indeed be useful to us to visually see on the board.
Disappointing to see you're not going to do anything with this.

I did want to indicate a resolved workflow state with a different colour.

"If you are simply looking to improve the visualization of issues within the JIRA issue navigator, I recommend the free icnavigator add-on from Interconcept GmbH."

Good idea. Unless of course you are running Jira OnDemand

theidenreich there are no plans to remove lozenges from the ADG or Confluence. When I referred to the ADG, I simply meant that the mapping of the color blue to "New" or "To Do", yellow to "In Progress", and green to "Success" or "Done" is in line with a common Atlassian design pattern and JIRA will not support associating arbitrary colors with these statuses.

In a similar vein, in my comment I acknowledged that there is merit in the use case nskinner described, where certain "resolved" workflow states are negative and it's confusing to have them represented by the color green. However, introducing a solution for that specific problem is distinct from the ability to introduce an arbitrary number of additional status categories, which is what this issue requested.

I totally agree with @GeorgeLewe and @NickSkinner - what I absolutely don´t get is the argument about the ADG!
Even if there won´t be custom categories there should be the six from https://design.atlassian.com/latest/product/components/lozenges/ or at least the five from the confluence status macro. Or will the confluence status macro also be stripped down to only three??

Update: Based on some of the follow-up comments, it's evident that some of our recommended workarounds were too focused on the ability to customize the look and feel of cards on Agile boards.

If you are simply looking to improve the visualization of issues within the JIRA issue navigator, I recommend the free icnavigator add-on from Interconcept GmbH.

Thanks,
Dave

Agree with George Lewe and Others.
@Dave Meyer Atlassian I don't know if you realize it but you are quickly losing the faith of your customer base. I used to LOVE JIRA. I told everyone in my organization why it was great and why we should use it. I even convinced two non-development departments to adopt it. One of the best parts of using Atlassian software was the user community. And your dedication to that community. But now that has all changed. Atlassian somewhere along the way you started ignoring your customers. With your attitude of we know best. Our customers don't know what they are talking about and we can ignore the real world problems they are having with our software (do I need to mention the single largest user community voted issue that has been open for 10+ years!) Recently I was asked to provide a review JIRA for G2 Crowd (software reviewing company). In my review I gave JIRA high marks except in the area of customer support. In the review I stated what I am saying here: Atlassian no longer cares about it customers. In my own organization I am suggesting we drop JIRA in the near future largely due to of the changes you made to statuses (i.e. this issue). For now my organization is deliberately not updating JIRA until this problem is fixed because of the problems it would create.

I am a Business Analyst and I often fill in as a Scrum Master as well. I review hundreds of issues daily and being able to glance down a list of hundreds of issues and pick out the blocked issues (e.g. Red color) is a HUGE time saver. Furthermore, in all our JIRA workflows my organization has a backlogged (non-active) status. This means that we recognize this is a problem but it doesn't have enough priority to get worked on right now (sort of like this issue until you decided to close it). In both the examples I just provided your new three tier status system (open, in-progress, closed) doesn't work. And as George Lewe mentioned using third party plugins is not a solution to this problem.

Atlassian please stop going down this road. If you don't turn around soon (and start listening to your user community again) pretty soon you aren't going to have an customers left.

Unbelievable, bold, ignorant and proving again that Atlassian's strategy is to distance themselves from the user community and just do whatever they want. This is another slap in our face, just like the issue about the round space logos in Confluence. Suggesting a workaround that requires another expensive plugin is just adding to the disappointment. Prices have increased to a sometimes unacceptable level on top of that. This is diminsihing Atlassian's reputation further. Too bad.
We are using the following plugin to visually display status in filters. At least a bit of a relieve:
https://marketplace.atlassian.com/plugins/org.hakanai.jira.plugins.jirastatuscolor
How about it, Dave? It is a simple trick that this plugin uses. Put that into the product at least.

"Oh don't be silly Mr Bkic! Everyone owns JIRA Agile and if they don't they ought to! I mean, why shouldn't you give us more money so we can continue ignoring issues such as this one?"

Obviously, I am less than satisfied with Dave's response to this issue - as it requires a purchase JIRA Agile. I wouldn't be surprised if this simple fact was part of the reason Atlassian limited status categories in the first place.