Is there a way to add some old view functionality back (i.e. choose the location of the field AND have it be hidden when empty?) 

In the new view, the ticket views look really heavy if fields are empty, but if you choose to "hide if empty", the entire ticket looks super messy and unorganized. Would love to have a common middle ground! 

For description fields - such as those in tabs , we would like to be able to hide any fields that do not have information in them from the view screen. 

Is this implemented for the Jira service desk as well?

Is there a way to completely hide the filed if there is no value to the field?

I found a workaround for those of us who are still using the classic view and want to see fields that are not populated.  In short, if you set the default value to the "|" character (no quotes), then the field will show up on the main screen and it will look like it has no text in it.  Then a user can click next to that field and edit it normally.  Note that this does not work as cleanly in the New Issue view (it creates an empty table cell) in that field which is a little harder to fill out.

More detailed steps:

1. Click Gear icon in upper right (Settings)
2. Click "Issues"
3. Click "Custom Fields" in left sidebar
4. Navigate to the field that you want to show on the main screen, then click the three dots on the right and click "Contexts and default value"
5. Click "Edit Default Value"
6. Put "|" in the field with no quotes.  This is the "bitwise-OR" or "pipe" character you can get by typing Shift+\
7. Click "Set Default"

Now new issues you create in the old view will show that field with no text in it.

I dug a little deeper as this functionality would be highly desirable with one of our issue types.  Unfortunately I was unable to find a special character that both

1. Makes the fields show up in both the new and old issue views and
2. show up as empty in both views.

I tried various combinations of the following special characters with no avail: <space> <newline> * _ | - # [] {} <> + . ' " ~ ` ! $ % ^ & = .  I tried different combinations of the character by itself, with a space next to it, with two characters, and with a space separating the two characters, but no luck finding a good one.

TL;DR If you need the issues to look consistent between both views and show up in both views I would recommend setting the default text in the field to ' or *.

Definitely needs to be added to classic view.

New Issue view works for workflows that are very comment driven.

For workflows that are form-based it's useless.

It is those form-based views that require this capability to show empty fields.

Echoing the request to enable this for the classic issue.

Seeing the ticket moved into In Progress after the February update from Taylor, does it mean it is now being worked on for classic view? Would be great to get a timescale of when the release timeline for this looks like. 

Many thanks!

Echoing the request to put this into the classic issue view. The New Issue view is not usable for us. 

If you found your way here, remember to comment on Jira/Atlassian's facebook posts, too.  Seems needed, since they're really trying to ignore the problem and roll-out this travesty of UX hubris.

I was involved in a product usability/feedback session with the core team.  The person that interviewed me was surprised that I was having such a bad time with 'new view' that it was a hard-stop for our teams.  Either Atlassian has a terrible system for listening to feedback (like these comments), or someone there is arrogantly trying to ignore it (to save their job/reputation?).  It's bad, and we will all suffer unless we make it more visible.

Please address the issue ASAP for Jira Service Desk so we can display empty fields on Support tickets so me and my colleagues do not need to go and click edit on every single ticket to fill in the empty fields.

@zak2 100% agree with you on all points, I don't grasp how it even got approved to be released.
There are way too many issues, to list a few.

• No Edit option (like the old way, where you would be able to edit any field even if they don't show up on the display.
• No templating, which means if you want to organize in a specific way for your company, you have to do it manually on each project for each issue type (yucks)
• And what is it with all the spaces and padding, you'd have to scroll pages down just to get to the field,
• Don't even get me started with the grouping.

Definitely not enabling New Issue View, due to the range of problems associated with it.  The inability to control fields anywhere on the card is a major drawback, and the groupings that Atlassian have chosen are not intuitive to any employee of any company I've been at since the new view was launched.

What's worse is that New Issue View doesn't even solve JRACLOUD-2997 — since empty fields are still hidden from the main view.

I think the edit diff on this post says it all.............

It didn't help.

New issue view is enabled for me,

The field that I need is mentioned in the "Primary Fields" section on the "Issue Layout" page for my "Issue Screen",

But it's not shown on the issue itself.

> Atlassian Update: 23rd December 2015

It is funny/sad that they've been soliciting feedback on this for 4 years, and the issue was opened 15 years ago.

• Is Atlassian just like 5 feature engineers, to keep costs low and dividends high? 
• Is the Core feature-poor so that there is a bigger marketplace that their friends offer plugins?

I wish someone would write an expose on this company

Agreed. This is one of the most consistently frustrating aspects of JIRA, and one that I constantly have to explain to our teams. Some fields simply aren't visible until you put data in them - as if that made any sense at all! Every freaking time, we are staring at the screen thinking where the heck is that field? Oh yeah - I have to put some nonsensical placeholder value in there so that my users can even see it. Ridiculous.

Are you kidding? This request is in Top-16 of all your requests!

https://jira.atlassian.com/projects/JRACLOUD/issues/JRACLOUD-2997?filter=allopenissues&orderby=votes+DESC%2C+priority+DESC%2C+updated+DESC

And you tell us you don't give a f what people need?

Same as previous comments.
Please look into having this available to the user.

Thank you

Totally agree - this is a BASIC MUST HAVE feature. One elementary example - custom field of type Assignment Group. You decide to remove the value and then at some point re-assign. But... as it is not visible, you can not. Atlassian need to start being more AGILE in their customer base requirements, I think this is clear.

I have had people at work ask me why they cannot see a particular custom field. I tell them Jira does not show empty custom fields by default and that they have to edit the issue to see all empty custom fields. They are surprised. Furthermore, I tell them there is no default setting allow me to determine whether or not to allow empty custom fields to be shown. They are surprised. I tell them, more or less, that this issue has been open for about 14 years. They are surprised.

What happened to the principle of least surprise? This is disappointing. What is especially disappointing is that Atlassian have not given a reason as to why their Product Management team have chosen to ignore such a popular feature request yet periodically ask me for Product feedback.

We need the ability to select visible or not per field, very cumbersome to go back to the edit screen when the field could be easily edited from the view screen. 

In the new issue view, the fields still only appear if there's data in them (e.g. Sprint shows only if you've assigned a sprint, same with  Story Points and Epic Link). So you have to click Edit and scroll down to find those fields and put entries and THEN they'll appear in issue view. VERY CUMBERSOME. 

It looks like the new issue view being beta tested on boards works like this.  There's no Edit button anymore - it's all inline.  I'm guessing that if/when that becomes the standard issue view, this request will be obsolete.

Voted for this..

This is a very important change to have implemented at my site.

We want users to be able to create tickets, without locking fields as required or setting them as defaults (since this can cause potential error), but it becomes tedious to monitor tickets when you can't even be certain of which fields are unfilled unless you hit the edit button.

Ok voted

In the corresponding Jira-Server-Issue (https://jira.atlassian.com/browse/JRASERVER-2997 , >650 votes) Atlassian noted that "This request is considered a potential addition to our longer-term roadmap."

Are there any plans to push this for Jira CLOUD, too? I think everybody would appreciate it if this usability feature was on the short-term roadmap...

Is it really that hard to implement?

Wait two more years and jira closes this as "too difficult to implement"

Can someone at Jira edit the Description to remove the "this is not in the roadmap" comment from Dec 2015 (2years+ ago). 500+ votes so far.

Just like "Fix Version" or "Labels", I'd like Epic Link to be displayed on a screen, so I click the little pen icon to set the value, WITHOUT having to click the Edit button and set the value in a popup.

Using the "Where's my field" in the Admin menu tells me: "The field 'Epic Link' does not have value for issue xxxxx and will not be displayed on the view issue page. Set value for that field so that it shows up."

This is bad that I have to open a popup to edit a field so that it displays, I want it always shown with the little pen to edit its value, starting from an empty field!

We've ran into this issue too. The minor annoyance is that there are default Jira fields (Component/s, Labels) that do exactly this already, but if we want our own fields, it's tough.

A workaround of "put one of the choices as 'None', and set this as the default" doesn't quite work - it would make the field appear, but the field would have a value.

@Sharlyne Tsai, I might be missing something, but if you edit the issue (i.e. press "E") you should be presented with all available fields for editing including the hidden one. If the due date doesn't show up for you, check your settings in the upper right corner to see whether you might have filtered out/hidden the field explicitly (might be the default behavior in your instance). Alternatively you might be lacking certain permissions, which would explain the missing due date, or the project is not set up accordingly.

With regards to this issue here, this is just about the effect, that if a (custom) field has no defined value, it won't be displayed when viewing the issue. This does not (as far as I'm concerned) impact the displayed fields when editing the issue and once you set a value for the custom field it should be displayed when viewing the issue as well.

Wow so close to 500 votes and this still isn't on the radar.

In our instance, I'm finding this feature to be a design flaw in the application and would welcome this suggestion as a solution. We created a task without a due date and now when we edit the task, we cannot add a due date. It seems like the only way to fix this issue is to recreate the entire task. This to me is not the best solution as there are comments etc already posted to the task as well.

So much administrator and end user frustration for so long...

I wonder if one of the reasons for not doing this may be concerns over backwards compatibility?

I think this could be implemented in a backward compatible way quite easily.

• In the field configuration, admins currently have the option to Show or Hide any field. Why not simply add a third option called "Show always"?
• The existing "Show" option could be renamed to "Show non-empty" or something similar.
• Administrators who select the new "Show always" option would then be able to show the field on the issue view screens, even if the field is empty.
• Administrators who don't select "Show always" will still have the old behaviour. 

Bonus points: Make "Show always" the default option for newly created fields. It seems to be the behaviour most people expect, especially with inline editing in the picture.

P.S. I came back to this issue again (I voted for it years ago when working at a different company) because admins at my new company tried to work around this problem by adding a "" in some custom text fields just for the purpose of getting the fields to show up in the UI. This made the fields show up but was a bit of a disaster because it turns out you can't search for just a dash in a text field (it's a special character that isn't indexed). Undoing that was quite painful. Being unable to search for those values made it very hard to do a bulk edit to clean things up. I finally figured out I could look for NOT EMPTY and then sort by the text field so that all the "" issues were at the end, and manually deselect the issue that had actual text. Fortunately we didn't have too many issues with actual text in the field when this issue was discovered. See JRACLOUD-40917 for more details.

Another stupid workaround (default value = null) that you want to keep in your product. 

Thanks again, Atlassian. 

Do you now what is the number one improvement issue our Cloud users have asked for? This one. They are constantly frustrated that certain key fields that start with no value are not visible when they open tickets. The stupid thing that most of them we have had to create a default value of "Null" - how dumb is that? In some cases, we cannot do that as we have some date fields that need to be set, but the users cannot find them.

Come on Atlassian, at least give us the option to display a blank field in the settings or something!

As many commenters pointed out, showing specific fields even when they are empty has valid uses. On the issue screen, as admin I have an "Admin" menu with an "Add field" option, but if you try to use that to add your custom field with an empty value it still does not show up - which is not what I expect to happen. Using the "Where's my field" option in the same menu I can find out that it's because the field is empty, and while that is quite helpful, it does not solve the issue.

In my case, there is an optional field that is still used a lot, and which my users often forget to flll out when needed - not knowing how to find the field once the issue has been created, or having to go through convoluted hoops just to fill it really gets annoying over time.

Using a dummy value to force it to be nonempty and thus be always visible just compounds the problem. Leaving a field empty has valid meaning, using an arbitrary value can only cause other problems down the line.

I had a team that's moved from TFS to JIRA ask me about this today.  I've been using JIRA since 2004 so I know very well why it's like it is:  They wanted a clean UI as opposed to other tools which display sometimes 30-40-50 fields that are usually blank.  Also there was no inline edit mode, so you had to Edit to change things anyway.  Back then one training session quickly answered the "Where's my field?" question and it was fine.  However, once they added inline edit (a great feature), lots of people went to this as their primary editing choice.  So now it's much more noticeable that you have to click Edit in certain situations.

I would really like an option to Always Show in the custom field config or screen config.  I greatly prefer JIRA to TFS in general but this particular issue causes me to have to do a lot of explaining to users.

+1

This ticket has 207 watchers and you email every one of them with each comment.

Everyone please take note and refrain from commenting unless it's something productive to the issue.

P.S. Apologies for the additional spam this message causes.

Yet another ticket that Atlassian has stated they will not work on. This time someone from their support team even pointed me to the ticket. At this point it seems like the product is on it's way out, and we're going to have to start looking for alternatives. There is nothing pointing to any development being done on the product anymore.

I just ran into the same problem. And came to this issue via http://blog.servicerocket.com/adoption/blog/2015/04/dude-wheres-my-field .

As a customer I am seriously disappointed by Atlassian. They are selling agile products and have ideas like "Vote Buttons" - and from the many other issues we ran into with JIRA and JIRA Service Desk - I am pretty sure no one at Atlassian cares about how many votes some issue has. They have there Roadmap and what customers actually want is not really important to them. This is very frustrating. 

And all other fields should be visible as well. For extra credit - preferably empty field visibility be configurable via Screen Configuration of Field Configuration.

Hoping they do the same for the SPRINT field.

The 'Labels' field is now always visible, even if it has no labels yet

This has made this field really much more usable, and it's a really good addition for the 'always viewable concept', as it is a field which values are dynamically defined by users (unlike most custom field values, which can only be defined by JIRA Administrators).

Many custom fields can be substituted by self-explanatory labels and, in that regard, I have to congratulate Atlassian's decision to make the Labels field an additional ever-viewable field.

Thanks!

I would like to see default fields like SPRINT be showing when there is no value, as we do for Component.   It only shows in the Details view when there is a value added to the ticket.   It seems counter intuitive to have one field by default and not another.    Please either open a related ticket or add this to an upcoming release

Created:20/Jan/2004 5:29 PM

IS THIS FOR REAL?!

Helps to have a flag for all custom fields based on which a field can be displayed on screen (possibly): Screen display: Yes/No

Alternately, allow users to type a keyword (possibly) * SCREENDISPLAY * which will do the same (which may be less intrusive from a UI perspective).

Please add this. So dumb that this applies to Story Points!!

Is it really too hard for you to provide an option to show empty fields? Or is this another one of those silly philosophical issues like issues don't need global IDs that don't change when an issue is moved between projects even though for most people that's just common sense  - kind of like the having the option to show or not show empty fields on the screen.

christoffer.ainek1994920185 you can try the solution I've created.  However, I'm afraid I don't have the availability to diagnose any issues which you might run into...

https://github.com/theschles/JIRA_ScriptRunner_AlwaysDisplaySelectList

This is still relevant. I realize that atlassian might not want to resolve this - does anyone else in the comment thread know of any good workarounds?

I'm trying to get the employees at my new company to use JIRA (like I did at my old company) - they currently use Excel spreadsheets. I'm in the process of getting everyone swapped over, but various things keep coming up that they take issue with and make them want to go back to Excel where they can always see everything they need to. This is one of those issues - it is confusing to a new user that an important (what we deem important on our project) field is invisible unless you click some other button. I can (and am) telling them to click the Edit button to view the other fields we need to fill out, but they forget and/or get frustrated that this is even an issue.. and frankly I'm going to join them in that sentiment.

Atlassian - I hope you change your minds and let us decide what is important to see on our various projects.

Thanks : ).

sad

I'll never understand why Atlassian always seems so completely against their customers being able to control their own content. This is just another example of that. Just like not being able to specify "target="_blank" for links in confluence.......8 years after it was requested. Sad really. 

Hi Mike,

Kavian's right.  Would you please post to the Issues section for the GitHub repo?

https://github.com/theschles/JIRA_ScriptRunner_AlwaysDisplaySelectList/issues

We can then try to figure out the issue together...

Please don't use the Atlassian issue to debug problems with a third-party plugin. Remember that the 167 people watching this issue and interested in updates from Atlassian will be notified for every comment you add.

Well I installed ScriptRunner and downloaded the code above, dumped all the files except the README into /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/jiracredits/scripts but following the instruction in the README, when I enter the path /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/jiracredits/scripts/configurationScript.groovy I get the error:

unable to resolve class com.bd.rspeng.alwaysDisplaySelectList.AlwaysDisplaySelectList

I must have done something wrong..... It appears it can't find the stuff I just installed. Not sure how this works...

We're using the OnDemand version of JIRA, which in a lot of ways is suckier. For instance, I don't think ScriptRunner can be installed on it. But thanks though. I think that would actually overcome the issues we're having were we able to install it.

Hi Mike, Eugen, and Phil,

Have you tried adapting my ScriptRunner script to your situation?

https://github.com/theschles/JIRA_ScriptRunner_AlwaysDisplaySelectList

I wholeheartedly agree with Mike Miller and the others. This is needed or at the very least a feature has to be added so a user can access these fields and enter a value. Not having this makes the product less useful than it should be.

To me this is a no-brainer. We have a couple of custom fields set up that we don't want to make "required" for various reasons but we do wish to encourage their use. If they're "hidden" by default (without a value) then it only discourages their use.

PLEASE implement this.