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.
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:
I don't know any other way
>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)
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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..
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.
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
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.
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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs