How can I get rid of the default "None" value in a custom field drop down menu

[Damien Cunningham]

In Jira Cloud I have created a custom field (Select List single choice) and defined two values to choose from. However there is a 3rd value of None by default in my drop down menu. Given my two required values are Yes and No this 3rd value looks slightly odd. How can I remove it as an option.

[Gaston Valente]

Damien,

you can try

1. selecting a default value for the field
2. mark the field as mandatory in the field configuration 

[Damien Cunningham]

Hi Gaston, Thank you yes this worked but is it the only way to do this ? I may not always want this field to be mandatory.

Thanks

Damien

[Gaston Valente]

You can modify the template but I'm note sure if it's still working in the last version of jira, it's an old article:

https://confluence.atlassian.com/jirakb/how-to-remove-none-from-a-select-list-custom-field-144212308.html

I don't know any other way

[Steven F Behnke]

The only way out-of-the-box (and thus in JIRA Cloud) is to mark the field as Required and with a Default Value.

[Nic Brough -Adaptavist-]

>I may not always want this field to be mandatory.

You can use different field configurations for different project/issue types.

Making the field optional requires you to have a placeholder for "not answered" - JIRA displays this as "none" (and removes it from mandatory fields that have a default because you don't need it)

[Alis-Hathway Ward (DO NOT USE)]

One work around for this problem that I've discovered with other fields is to add a post operation to your transition state for To Do.

E.g., if it makes sense to do so for the field you've created, simply add a post-operation for that field on To Do to set it to your default. Then whenever you create your ticket, the field is automatically set to the desired default option. 

The side-effect is, of course, that if this field is not supposed to be changed when putting a ticket in To Do (continuing from the above example) from any other state, it will reset whatever status was already in the field to whatever you designated for the Post Function.

It's not a perfect hack, but can work well in certain situations where that's desirable behavior forwards and backwards (like clearing out Resolution automatically, so that you can require it for other transitions, set a desired fixed default in jira, and then tell people to just ignore it when creating tickets because it'll auto-transition back to Unresolved for them anyway.).

[Dave]

The idea that the application should insert an arbitrary value into your list is nuts if you don't supply a default. Doubly true if a response is required. If I have a single select for a color field with choices Red, Green, and Blue what should that default to? What color is 'None'?

It's not consistent and if this was a good solution then why aren't empty text boxes automatically filled in with the word 'None' if someone attempts to submit an empty text field that is required?

It's just another Atlassianism.

[Michael Lasonde]

Could someone supply me the solution to get rid of or rename the NONE option for a Single select dropdown? I found a very old post about modifing the edit-select.vm, I attempted it and it didn't seem to work. Any help would be greatly appreciated. I should add that Im using a host solution not cloud

[Joe Pitt]

And this is exactly the reason NOT to edit code. When a new release comes out you may have to rework all the code edits you have. Why does None bother your users so much? I've supported many users on multiple JIRA systems and they never had a problem understanding it. 

[Nic Brough -Adaptavist-]

I'll go a step further and point out that I've removed those hacks before because people don't get that an empty line means "none".  I've never had any problem with users not understanding "none".

[Michael Lasonde]

While I appreciate your opinions, my users are not able to distunguish "None" as a field that needs to be selected.. Heres an example, if I make a field required such as Data Center and in that drop down I have 3 options.

None

Americas

EMEAR

China

They think that None is a viable option to select within the field. I don't need to completly get rid of it but renaming it to something more intutive like " Please Select" or Select an Option" Something along those lines.

Is their a solution to this? 

[Steven F Behnke]

No one here would recommend that you make a change to the source files for a problem so slight.

[Michael Lasonde]

Please use the term slight loosley, If by slight you mean 10's of thousands of users and a vast amount of projects with this particular field being the majority of the fields used within numerous customer portal's...As previously stated its the word NONE that is the issue not simply being that a word exists. Changing the word would yield the same results and at the same time more intutive and be better adopted by the end user.

[Steven F Behnke]

You can take what I said however you'd like. Neither Nic not myself think it's a smart effort and likely can't create a walk through for you because we don't perform the same customization ourselves. 

If your like to post the file you edited, it's possible we could provide feedback since we're both comfortable with Jiras implementation of velocity templates.. 

[Michael Lasonde]

Thanks Steven, I think I'll explore other options, although slight to some, I need a fix not a run around by someone not really willing to help.

By the way this "None" option has been a point of concern by many since 2003. 

[Steven F Behnke]

As I indicated in my previous comment, if you'd post the file you edited, Nic and I would be more than happy to look it over for errors. We can't give you any advice without either the source code or a list of errors you're receiving. 

[Nic Brough -Adaptavist-]

Atlassian have stated that all their UX research indicates that "none" is the best way to handle this.  So it's not going to change, because it's simply not a problem for the vast majority.

I agree with Steven - just because we think you're doing the wrong thing, you've asked, you've seen why we think it's wrong, and it's not something that's bad, just a waste of time that will probably lead you to want to remove it.   But even holding a negative opinion about it doesn't mean we won't try to help you (we would refuse if it were dangerous, but this isn't)  Can we see what you've done with the file?  And erros.

[Michael Lasonde]

1. I Changed class.resource.loader.cache from true to false

2. Uncomment  #velocimacro.library.autoreload=true

To rename the field, I edited <jira install dir/WEB-INF/classes/templates/plugins/fields/edit/edit-select.vm.

I modfied the lines: below (with "common.words.select" as a replacement for("common.words.none")

There are no errors, just simply doesn't seem to work on any existing custom fields or new ones.   

#if (!$fieldLayoutItem || $fieldLayoutItem.required == false    <option value="-1">$i18n.getText("common.words.none")</option>  #else    <option value="">$i18n.getText("common.words.none")</option>  #end 

[Steven F Behnke]

Can you confirm that you Restarted the application after changing the cache configuration? They aren't picked up during runtime. 

[Michael Lasonde]

I did not restart, Were on a production system at the moment. 

[Steven F Behnke]

Understood. The configuration to reload templates is not picked up during runtime, only restart. 

Setting the configuration saves you from needing restarts in the future, but you'll need to restart first to get that enabled. 

[Michael Lasonde]

thank you will try on off hours

[Nic Brough -Adaptavist-]

Before you restart, change this one back:

"I Changed class.resource.loader.cache from true to false"

It's fine in a development system that's going to get restarted soon, but without the cache enabled, the templates gradually chew up space in memory and will lead to performance problems eventually.

[Tiffany Owen]

Michael, did you ever find a solution for this? I would also like to change the word from "None" to "Select an option"

[Michael Lasonde]

No everything I tried was not Successful. Sorry wish I had better news. 

[BigBrother]

Strictly speaking, making a field required is *NOT* the only way to do this in JIRA cloud. Better yet, you don't need someone else's add-on or to make a field required through the field configuration scheme.

The answer is checkboxes! Hear me out.

If you only need this to be required for certain transitions in certain projects, this is the easiest way to get that kind of flexibility:

* To get rid of the "None" option, use checkboxes instead of radio buttons or drop-down lists.

* Go into the project's workflow

* Open the "Validators" section of the transition you want this field to be required for

* Select the "Field Required" validator and apply it to your checkbox field

* Select the "Field has single value" validator and apply it to your checkbox field

Ta-da. If you need it to check for specifc values, just add the "Regular Expression Check" validator. Note: this validator looks scary because it mentions "Regular Expressions"- be aware that you can also simply have it check a value against a string/plaintext word/phrase.

Checkboxes may not be as sexy as a drop down list, but it gives you incredible flexibility that no add-on or "make this required in the field configuration scheme" solution will give you.

[Nic Brough -Adaptavist-]

Not quite, and the solution is wrong too.

The reason it is wrong is that you've used the wrong type of field.  A checkbox field is a a multi-select field with a different display.

You should have used a radio-button, as those are the same as single-selects.  Of course, if you swap to a radio button, you'll now find it gets the "none" unless you set a default and make it mandatory.

A validator is a poor way to do this too, because you're not telling the user that the field is mandatory until after they've tried to commit.  It also allows the user to empty the field out in edit mode.  So it's clunky and ineffective most of the time.

[BigBrother]

Most of the time? Not in my experience. It's flexible and it allows for what the OP wants. Of course the user can empty the field on the edit screen- just like they could change the option in the drop down list or make a different selection with a radio button. And if that's a deal breaker, just hide the field from the edit screen but keep it available on the view/create screens.

I see the validator checking the field during the transition as a huge win- instead of just hiding a transition like an unsatisfied conditional does, the admin can make a custom error message shown to the user.

So yes, the solution works and it is exactly what the OP asked for.

[Nic Brough -Adaptavist-]

No, please re-read what I said properly.

The OP wants a single select list.  You've given them a multi-select.

We don't have the full requirement for where the field should be mandatory, and a validator *might* be right, but we don't know that.

So, the solution does not work and is not what the OP asked for.

[BigBrother]

The OP created a field as a single select list because they want only one option to be accepted. Whether that's as a single select field or a multi select field that requires only one value, that's up to them. I'm giving them options.

If you were to read the rest of the OP's comments, they say they *don't* want this field to be required all the time but they also want the "None" option to disappear. Forgive me and my limited knowledge, but a single-select field will _always_ have that "None" option unless it's made required in a field configuration scheme... Making it a field that's always required in that project. As per the OP's comments, this doesn't satisfy their requirements.

This is an extremely flexible option that fits their requirements. So yes, the solution does work and is what the OP asked for. The fact that it doesn't fit your paradigm doesn't mean it's invalid or wrong.

EDIT: However, as it's clear we won't agree on this, I'd admonish the OP to try both and see whichever option works best for them.

[BigBrother]

I posted an answer as a response detailing why my solution doesn't fall victim to the OP's mutually exclusive deal-breakers your solution provides, but it's since been removed. I assume by the partner champion who disagreed with it. As far as I understand this community, there's nothing wrong with providing additional options to the OP especially when these options are completely valid and solve the problem. So I'm going to post it again because I refuse to limit the OP's options. [/rant]

The moral of the story is this: the OP has a problem, your solution doesn't satisfy his need for the field to not be constantly required as well as not showing "None" as an option. My solution does. The OP can choose, don't delete my answers because they clash with your paradigm.

A multiselect field very easily becomes a single select field with a validator, it very easily solves the issue of removing Atlassian's extra "None" option, and it very easily can be required when and where it's needed with a validator.

By all means, OP, use checkboxes or go use field configurations with project-scope required fields. Whatever works best for your setup.

[Steven F Behnke]

You can't get validate edit operations so that would useless for my customers. 

A checkbox is not the same as a select list. The controls have different semantics and are used differently. 

What do you mean someone deleted your post? No one deleted anything. 

[Nic Brough -Adaptavist-]

No, you're not getting it.    Your solution is wrong because it's for multi-selects (and happens to be clumsy for them).  There's no "opinion" or "agree to differ" here, it's a straight, black-and-white fact that your solution is incorrect.

Imagine a simple case - I go to buy a car, and I say "I want a red car, with a blue knob on the volume control for the radio".  Your response here is the equivalent to "we have a green wheel barrow, with a blue handlebars, so that works better than a red car with a black knob".

Now, we don't know exactly what the poster means by "only mandatory some of the time", so we don't know if validators or field configurations would be better.  So we don't need to discuss that.

[BigBrother]

I'm painfully aware that they're not the same. Using a different type of field, like I suggest, takes care of both of his concerns.

The OP wants the ability to provide options to the user without the obnoxious "None" option of a radio button. Using a multiselect field (like a checkbox) removes this "None" option; add a validator that prevents multiple options from being selected.

This lets the OP make it required when and where he wants as opposed to through field configurations defined for the whole project.

[Nic Brough -Adaptavist-]

No.  It does not.  He stated "single select".  You've given the wrong thing.

[Steven F Behnke]

No, the None text is there opposed to a select field with no text in the label. 

The HTML difference between the two can be displayed between these two examples: 

<select>
  <option value="-1">None</option>
  <option value="$optId1">$optName1</option>
  <option value="$optId2">$optName2</option>
</select>

 <select>
 <option value="-1"></option>
 <option value="$optId1">$optName1</option>
 <option value="$optId2">$optName2</option>
</select>

Effectively, Atlassian for some reason decided that's how the select lists should look and it has stayed that way ever since. There's no configuration to change it.

As Gaston suggests, those running JIRA on their own servers may dig deep into JIRA's files to customize the template that renders the field but this option is not avaliable in JIRA Cloud: You can't just edit any arbitrary file.