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:
I'm not an admin.
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.
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!
+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.
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?
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.
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.
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)
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.
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.
Look at the field at the root of this as just one example - status
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.
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:
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.
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.
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, 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
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"
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.
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.
+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.
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.
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.
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".
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.
> 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.
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.
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:
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?
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.
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.
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.
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.
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.
We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...