Can't add standard "Status" field to issue navigator

[Liam Bottomley]

This question was raised here. However the resolution is not satisfactory.

In the issue navigation (Issues>Search Issues), when trying to add the default field "Status" as a column to my table of results, I search "Status" I get the response of  “33 more options. Continue typing to refine further.”

I cannot refine the search any further as I am looking for "Status" but the options presented in the list are various fields containing the word "status".

Suggestions made in the other question:

1. Remove the other fields with "status" in - This is not an option, they are in use.
2. Edit the HTML of the page - I have not been able to successfully achieve this, nor should I have to.

I'm not an admin.

Jira v7.2.7

[Melissa]

I am shocked to find this is still an issue after so long! I am not administrator or even the project owner. We have lots of teams with lots of statuses and possible (I can't see them) lots of custom fields. 
All I want to do is add a filter so that I can see anytime the status is not in or in certain states. And yet each time I try to build a custom filter for this the status piece never works. As far as I can see the column is just called 'status'. There are no other options or names available to me. 
Please, please resolve this. It's such a minor thing but is making life finding all my tickets I am not assigned to very difficult when there are hundreds of Done ones and I only want the non-Done status ones. Thx. 

[Filipi Lima]

Hi all,

This is a suggestion that would address this and has the most votes and attention. Add your vote there as well if it affects your team.

See more available fields for Columns in Issue Navigator without typing 

Cheers,

Filipi Lima

[harryb888]

Thanks - I voted. JIRA has been open since 2016...

[roger.owers]

Voted, although I feel it is pointless

[Ed Jones]

Ditto.

I does feel like the whole issue is being over thought.

Let's assume that massive organizations are never going to (be able to) fix their fielditis. And, let's not forget; Jira _allowed_ us to get into that state, which they so decry.

The simple fix is just to change the "X more options. Continue typing to refine further." text to a link that says (something like) "X more options. Show all."

As I've said before; the options are _already there_ in the HTML, we just need an easy way to see them!

[Ryan Bullock]

+1 for a permanent fix for what seems like a simple problem. In our case it's not the word 'Status', but 'Type' 

Fielditis is certainly a factor, however designing a user-friendly interface is important as well. As people have noted, it's not the easiest to control fields across an entire organization.  

[Nic Brough -Adaptavist-]

It's much the same answer - if you have 25 "type" fields, you've probably got 20-24 too many.  Are they all really going to useful in reporting?  Do your people actually use them all correctly?  Obviously, you're not in the slightest bit Agile, but is your Waterfall process doing what you need?

[roger.owers]

Came across this again this morning, wasting hours of my day, finding the html to fix, can you please just allow an exact match to appear at the top of the column chooser?  I just want to use the system, the custom fields are out of my control, this really is awfully painful.

[Nic Brough -Adaptavist-]

There is not going to be any fix for this in the code for the foreseeable future.  Your only proper fix is to beat up your admins to fix your fielditis problem.

[roger.owers]

Hi Nic, unfortunately one of the great features of Jira is the ability to have custom fields and to name them useful names, we currently have 44 fields with status in them so that's just not going to happen.  It would be a useful and hopefully very simple feature and would save users time.  Having to get stuck, not understand what is going on and then find and implement the workaround, which would be beyond most users confidence level.  Can't imagine how much time we waste on this and others in the community for a simple "include the exact match at the top" piece of functionality. 

[Randy Wilson]

+1 for this simple fix to correct an issue that Atlassian has left unresolved for years

[Nic Brough -Adaptavist-]

You do know I'm quite familiar with Jira?  Only been using it since version 2...

I've spent most of my career with Atlassian stuff seeing problems like this, and "it's not going to happen" is something that just tells me your organisation is broken. 

You're absolutely right that you're wasting vast amounts of time, but you're pointing the finger at the wrong place - you need to address the problems that have lead to your "fielditis" (it's not directly a problem itself, it's a symptom of a bigger broken thing)

[Nic Brough -Adaptavist-]

@Randy Wilson- there's nothing they see as a "fix" - this was a deliberate improvement made a few years ago.  You would be better saying "a design flaw that affects people already suffering fielditis"

[roger.owers]

I think if I'm a user of Jira and I can't get one of the most common fields added to a simple view of my data without hacking the html, then it needs a fix, to me it looks broken, "where is the field?" oh it's further down the list but you can't see that... "er so what do I do? ".. well you have to hack the html code see here it's really simple, here's a 12 step process.....  it's absolutely a design flaw.

[Nic Brough -Adaptavist-]

Yep, but it's not a bug, because it's working as intended!  Atlassian have closed the requests for a change with "won't do" type messages, indicating the "workaround" is essentially "do something about your fielditis".  Not ideal.

[Randy Wilson]

Definitely a design flaw, and more importantly a customer support failure.

[Nic Brough -Adaptavist-]

Actually, I wouldn't call it a customer support failure, it's actually encouraging the customer to improve their process and usage...

[Jor Bratko]

I asked the question in a comment on this page last October about where do I find help in curing fielditis, but my comment didn't get any response. Is there any guidance on handling fielditis? Docs, articles, etc.?

[Randy Wilson]

I’m not sure how many different ways this can be stated. In a large organization, “fielditis” is not under control of end users and likely is a fact of life. Lectures on optimizing business process are not helpful, and miss the point entirely.

[Nic Brough -Adaptavist-]

I'm not sure how many different ways this can be stated.  In any organisation, "fielditis" is a symptom of a broken set of processes, and is likely to be wasting a lot of resources.  Anyone suffering it should be telling the upper layers that there is a problem that can't be fixed by sticking your head in the sand, botching tools to try to get them to fit a broken system or ignoring lectures on how to get your business process right.

Be that employee - be the one that evangelises for postive change.  Tell your bosses you've wasted 12 hours because you're stuck with fielditis (reminder - changing the tool will just make it worse because people will just try to carry over all the bad things that have lead them here already).  Get the processes fixed.  Or just accept that you're stuck with a broken process and a tool that doesn't support that process and plough ahead.

[Jor Bratko]

Can you help me with the answer to the questions my boss will ask like, "What's broken about our processes?" So far, all I have is, "Because there are too many custom fields in Jira". That's not a business problem they will care about.

[Nic Brough -Adaptavist-]

Look at the field at the root of this as just one example - status

• Q: Where are we with this item?
• A: The status tells us that
• Q: Ok, great, what's the status?
• A: Which one of the 45 status available do you mean?
• Response: I have no idea,
  • why the hell have we got 44 totally useless status that don't tell me where we really are? 
  • why is one team telling me one thing and another team something totally different even though they mean the same thing?
  • why don't the numbers add up?
  • and
  • and
  • and

Rinse, lather, and repeat for all the other fields.  My favourite example is finding a system with well over 40 pairs of start and end dates.  Their reporting started to work when we got that down to one pair for issues, one pair for projects.

Your reporting is mostly useless as soon as it needs to be done for more than one team.  You have no idea what is happening across the system - it might well be working perfectly for each individual team, but I can guarantee you no-one has any sane reporting across the business units using it.

[Daniel Garcia]

I think you’ll find different businesses have different needs. Some need 45 status, some don’t 

[Ryan Bullock]

In our organization we were dealing with fielditis and subsequently issues with the search feature. As a way to reduce the number of fields in our system here is what we did:

• Reduce the number of Jira Administrators i.e. the number of people who can actually create fields
• We have a weekly Jira Administrators meeting where any change to Jira is discussed. For example, if someone wants to create a new field it is discussed as a group. There are often similar fields that can be used.
• Conduct a quarterly/yearly review of fields in Jira and delete/migrate fields
• Standardize.  Be less specific with your fields and be as general as possible. Reuse as many fields as possible.

I understand the search function is frustrating, but instead of waiting around for Atlassian to fix the issue (which they likely won't), there are small things you can do to help.

[Nic Brough -Adaptavist-]

Don't confuse "different needs" with "broken working practice".

[Randy Wilson]

Time to unfollow this topic, since the discussion is no longer relevant to the OP’s question about a problem with the software’s search function.

[harryb888]

I just got bitten by this. I happen to work in a large organisation and I can say whatever I like about fielditis but even if I complain vociferously it would take *years* to change. Much like Atlassian responding to valid customer feedback (I guess 3 years isn't long in Atlassian time). 

This whole episode reminds me of dealing with small children. The amount of effort Atlassian have expended saying they will not make the small fix that would make this problem go away is vastly more than the effort to fix it in the first place.

[Parthiban Thilagar]

May be someone has already stated this already.

If I am allowed to create a new field with a unique name, all of us with access to that data should then be able to use that name to retrieve and view the contents of that field.

Thanks to Mark Diamond for the work around. However, this should not be treated as an edge case requiring a work around or a hack at the end user level. Most of our end users cannot handle this.

[Nic Brough -Adaptavist-]

Option 1 is still the right thing to do.  You have "fielditis" and that's going to cause you other problems in the long run.

There is no "fix" for this, and as far as I can see, Atlassian have no plans to do anything about it.

[Randy Wilson]

What we are seeking is a workaround for those of us who have no control over the fields that get defined in a large organization. At a minimum, an exact match for your search should always appear at the top of the results.

[Liam Bottomley]

Nic, I do see the "fielditis" issue and it wouldn't be my way of working.

As Randy says, I have no control over the whole organisation, its a large multinational organisation (100,000+ employees) with a huge number of projects. I can see around 70+ Projects, plus there are those with more restricted access that I can't see.

It's unrealistic that I'll get so many fields removed - an exact match would be ideal.

I would be surprised if what Randy and I are experiencing is an edge case

[Nic Brough -Adaptavist-]

I'm afraid it probably is an edge case - Atlassian simply haven't had enough people complain to make it worth while going back to the previous UI (which had a workaround) or engineering something else that solves it.  And their answer for a workaround currently is, sadly, pretty much just "fix your fielditis"

[Randy Wilson]

In my organization, one of the admins did provide us a workaround that may work for other large orgs. We now have a template report available that does include the Status column, which we can then customize and do a Save As so that the column is included. We were fortunate to have an admin sensitive to the issue. It's not an ideal approach, and still exposes a flaw in the product, but we are at least able to show this basic information in reports once more.

[Liam Bottomley]

Hi Randy,

I'm glad you have managed to workaround this issue. I would be really interested to know either : How this template report was created or even what it looks like/ where in Jira you find it so I can attempt to replicate. I currently have temporary admin rights to deal with some other issues and clean up.

Thanks

[Ed Jones]

+1 for a proper fix to this issue.

Saying "you need to delete some of your fields" is akin to "you're holding it wrong" 

As others have said; we (as JIRA users in a gigantic multi-national development organization) don't have control over who creates what custom fields. And we certainly can't start telling other teams to delete theirs because there's too many with "Status" in the name.

As Randy says, it's a pretty simple fix; put the fields that match the search exactly at the top of the list, then those that start with the search string, then those that contain the search string.

[Nic Brough -Adaptavist-]

The "proper fix" remains fix your fielditis.  It's not just this one thing it is affecting.  A good Jira admin *will* go to other teams and tell them they have and/or are causing a problem.

There is another workaround, assuming your admins haven't let poor configuration creep too far.  Click "defaults" on the filter and then reconfigure again, remembering not to remove status.  The default default includes the system status.

[Ed Jones]

We have 140,000+ employees, thousands of projects that I have access to and, I assume, thousands more that I am not permitted to see, and they span a massive range of products and disciplines.

It follows, almost inevitably, that there are going to be a large number of custom fields with similar names. When I first click the Columns dropdown, it tells me that there are 1188 more options!

By using the HTML-hacking solution ( https://community.atlassian.com/t5/Jira-Core-questions/Can-t-add-standard-quot-Status-quot-field-to-issue-navigator/qaq-p/352494 ) I was actually able to get the Status into my filter. But it would be much simpler if this UI were more scalable so that we don't have to resort to such technical workarounds.

[Nic Brough -Adaptavist-]

Or you could ask your admins to fix your over-complex, counter-intuitive and anti-collaboration broken data patterns.

Don't get me wrong, I totally understand how your organisation has got there, and why it's so hard to fix, both on the corporate stupidity, and provider ignorance, side of the argument.  I've spent <mumble> years working in exactly the same places.

I hate "fielditis".  It's a bad behaviour whatever the alleged justification, and large organisations fail miserably to understand that.  Equally, Atlassian fail miserably to understand that large organisations are going to screw up by falling into that bad behaviour.

I lean towards Atlassian's simplistic view a bit, although I do prefer the interface from a few versions back.  That interface made it horrid for people suffering fielditis, but they could get there with a bit of effort.  The newer one doesn't do it at all.
But I don't think Atlassian will change it , because the idea that a UI has to be "scalable" usually means "we've made it too complex to be of any real use".

[Randy Wilson]

I (and probably the others on this thread) have “asked my admin” fifty different ways, to no avail. I too dislike “fielditis” but it’s a fact of life in a gigantic organization. 

You’re right to conclude that Atlassian won’t fix it, as most of us poor slobs who use the product have also realized. It’s a shame that such a simple, single-line-of-code fix is too much to ask. 

[Nic Brough -Adaptavist-]

I'd like them to go back to the previous implementation - you could at least work around that one.

[Ed Jones]

> It’s a shame that such a simple, single-line-of-code fix is too much to ask. 

Amen to that!

Heck; they could even just change the "33 more options. Continue typing to refine further." message to contain a link allowing you to display the hidden options. As the HTML hack (mentioned above) proves; those options *are* there in the page, it's just that they're not available without jumping through hoops.

[Norman_Heath]

This is a serious problem for us as well. Again a large organization with perhaps hundreds of issue types. Why this can't get fixed by Atlassian is a mystery. I thought those happy, young folks over there would be happy to fix a serious problem for several customers. Especially for large customers who pay large license/support fees.

[Daniel Garcia]

It’s a shame that such a simple, single-line-of-code fix is too much to ask. 

yeah, apparently it is an "Edge Case"

[Edward Gladstone]

As desirable as reducing excessive custom fields might be, it is not an option for many of us. Atlassian needs to add a simple "if" to the Columns chooser to list an exact match of the field search string FIRST in the list of fields.

In the meantime, see Mark Diamond's workaround at:
https://community.atlassian.com/t5/Jira-Core-questions/Can-t-add-standard-quot-Status-quot-field-to-issue-navigator/qaq-p/352494#M35109 

[Imran Shaikh]

Nic Brough, we have the same issue, and all these fields are used and cannot be deleted. This is not an "Edge case", any large organization will run into this. 

If Atlassian wanted users to not have so many fields, then they should have put some limits on number of fields that users can create.  Since they didnt, it means users should be able to create AND utilize ANY field that they create.  So no need to lecture anyone about some "disease" that some group of user may possess.  If a product has a feature, then using that feature cannot be considered a "bad habit".

This issue needs to be fixed in a manner that allows users to get to any field that exists, in a user friendly manner. 

Also, what makes you so sure that the company wont fix this issue.  Have you opened a ticket on this? Have you received a response from developers with their reasoning for not fixing this?

[Nic Brough -Adaptavist-]

It's no good trying to push all the blame on the application either.  This is a two part problem.

First, you've got broken processes or demands causing fielditis.  This disease you have is not just causing this one focussed problem, I can absolutely guarantee you it's causing problems across your reporting, your system usage and even culture.

Second, when you have this disease, Atlassian handles it badly.  I'm not questioning that it doesn't work and should really be fixed.  At the very least, the behaviour should be reverted back to the previous design, or better, the one before, where it coped fine.

There's not a lot of point in raising the issue again.  People have, and Atlassian closed it because the way it works now is their desired design.

The reason I lecture is simple - people just keep repeating the problem without admitting that they need to fix their fielditis.  When you've got the disease, it's pointless being in denial about it, and those of us trying to help can't do a lot else.

[Daniel Garcia]

I have several custom fields that have a single character field name. These are implemented as scriptrunner custom fields and displayed as an icon.

These fields have a single character for the fieldname because more characters would make the column wider and waste horizontal real estate.

When you search for a single character, it is likely you will get more than 25 matches unless I have less than 25 custom fields. Maybe having more than 25 fields is fielditis.

Additionally your (and many other people's) comments about fielditis being an indicator of broken processes ignores the context in which those processes are running. For some organizations and some processes this could be very true but a blanket assumption is a bit offensive.

[Nic Brough -Adaptavist-]

Ok, there's two mistakes there.  You have useless field names, and you have not read the comments about fielditis properly - almost all of them are framed in the context that they understand how this has got there and they clearly understand how the processes have become broken.

It's quite offensive to ignore that the posters have recognised how the data has become broken.

[Daniel Garcia]

The field name is plenty useful. I guess it depends what you expect a field name to do. In my case I expect it to not take up too much space.

Secondly the original post did explain how they got to the fielditis problem, but I got lost in other people responses. I understand your point.

[Jor Bratko]

Is there a criteria for when a new custom field is justified or when it is only contributing to fielditis? Is there an article or documentation from Atlassian which can help me administer for this? The only article I could find talked about not having too many fields in a screen, not overall.

So far it seems that the diagnosis of fielditis is based on if this UI problem occurs in your instance, which only depends on how many fields have the same string in their names as the shortest field name in your instance.