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.
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.
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.
+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?
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event