remove "None" form drop down selection?

[Chuck Oleary]

I have a screen created that uses a Custom Field that is configured "Select List (single choice)". 
I set the Default to one of the choices I created.

Why does the option of "None" still appear as a valid choice when it's not even in the list of choices?

Perhaps I need to make a selection mandatory? I just cannot figure out how to do that.

[Ste Wright]

Hi @Chuck Oleary 

Field's which are optional need a "None" option - but you can change that (per Project) to make the field mandatory.

Note: This makes it mandatory at creation, and stops a user from clearing values completely.

---

For a Company-managed Project...

1. Go to Settings (cog icon in top-right) > Issues
2. Select Field configurations on the left-hand menu
3. Open the configuration relevant to your Project(s)
4. Search for this field using the search box, then select the "Required" hyperlink under the Actions column.

A few notes...

• You need to make this change per field configuration, across all relevant Projects
• If you're unsure which field configuration a Project uses, either...
  • Per Project, check via Project Settings > Fields 
  • Select Field configuration schemes in the admin menu, and review the Projects column. If a Project isn't in there, it's most likely using the "Default" config

---

For a Team-managed Project...

1. Go to Project Settings > Issue types
2. Open an issue type
3. Locate the field, and open its settings (use the ">" icon on the right-hand side)
4. Check the "Required" checkbox.

A few notes...

• You need do this per issue type, per Project for Team-managed

---

Let us know if this helps!

Ste

[Matt Parks]

You do need to make the field required in order for 'None' to no longer show. You will need to do this in the Field Configuration, clicking the 'Required' link for the field in the configuration.

[Chuck Oleary]

I don't have that option for my Custom Field.  This is on Jira Cloud

[Matt Parks]

This isn't in the Custom Field configuration. There is a Field Configuration section where you would enter this:

I don't know if it looks the same on Cloud, but here is where it is in Data Center:

[Chuck Oleary]

Didn't work as expected.

[Chuck Oleary]

Turns out that while it removed the None option it caused another problem.

The way I'm using this is when a ticket is in active development and the team needs to pause the work and assign a reason why it's being put on hold.  The would select from the dropdown list.

The problem that happened after I made this required is a PM tried to move a ticket from a User Story ticket type to a Bug ticket type.  This caused them to get the popup screen, even though it is a new ticket is not being put on hold.

I really do not want to move forward with giving teams the ability to Hold tickets but have the None option as a choice.

I'm baffled on this one, I only want the transition to the Hold status from an active development state to make the Hold reason screen to be presented and the be reason from the dropdown be mandatory.

[Matt Parks]

Under what conditions should anyone set the Hold Reason field? Should this only happen when transitioning to a particular status?

What problem are you experiencing by allowing None as an option? How are you going to use the information in the Hold Reason field?

The reason I ask these questions is, on the surface, this sounds like a process problem, not a tooling problem. Allow the users to put in a value and, if they don't, have a discussion with them to let them know why it's important to have a value in that field.

You could also set up a query that shows all of the work items in that Hold status that don't have a Hold Reason set. That way you maintain visibility into issues that don't have the value set, so you can reach out to the users that aren't setting the field appropriately to let them know the reason why it's important to set the field.

[Chuck Oleary]

What a ticket in a sprint is in an active development state it could be put hold hold for a few reason, like awaiting customer feedback.  Since this could take several days or longer we could put the ticket on Hold and I can remove that from the Time In Status reports.
Plus None is not a valid reason so I do not want it selected at all.

We will use the Hold field in PI and sprint metrics.  It should give teams an indication where they can improve in splitting tickets, did they miss a DoD, etc.
People over process, why create another dashboard widget that everyone must look at to make sure they didn't take the easy way out and select the nebulous "None" choice.

Regardless if it's a process problem or not, this is what the teams wants to do, why MUST the option of None be there?

[Matt Parks]

Perhaps I mis-spoke (mis-wrote?) when I said process. I really meant that this is a people issue, not a tooling issue. Let your people know the right thing to do and then trust (but verify) that they're doing the right thing.

The short answer to why 'None' is an option is because, if the field is not required, you have to be able to have no value and, if there was a value selected already, you have to be able to clear it out.

I wasn't recommending that everyone look at the dashboard, just the person(s) who is ultimately responsible for gathering the information around why things are being put on hold.

If you have Scriptrunner, I know it is possible to make a field required only on a particular transition screen through a behavior. You also could make the field required on the workflow transition. In either of these cases, 'None' would not meet the requirement that the field have a value.

[Chuck Oleary]

It's a required field on a popup screen when a ticket transitions to Hold, why it is required when anyone moves a New ticket type from Story to bug?  While both use this simple example of workflow the story is not being transitioned to a hold status.

If I tell teams of software developers to just ignore and please don't use the nebulous None option it's just going to make them dislike Jira even more than they already do. And they are _very_ vocal about feelings on Jira, it's one of the main reasons we have not and most likely will not move to Confluence.  

[Matt Parks]

My guess is that when the field configuration was updated to make the field required, this is what caused it to be required when the issue type was changed from Story to Bug.

If you want the field required on Stories but not Bugs, you could create a Field Configuration Scheme that allows you to have separate Field Configurations for Stories and Bugs, with the field required on the Story Field Configuration and not required on the Bug Field Configuration. Then update your Field Configuration scheme used by the project to associate the Field Configurations with the appropriate issue types.

Of course, I'm making some assumptions, which is that you want the field to be required all of the time and that you want to remove the None option from the list. Note that this will also require you to set a default value on the field which, honestly, is where the whole thing falls apart.

If you can't get your users to put in a value on the transition screen, it is highly unlikely that they will put in the effort to make sure that the correct Hold reason is set (since it will already have a default value, which meets the requirement).

That's why this is really a people problem where you need to give your users a compelling reason to enter in the correct information into the field. If they think that it's just a "Jira thing", and they don't like Jira, then you're not going to get them do what you're asking on a consistent basis.

[Chuck Oleary]

I really don't see it as a people problem to have a superfluous option created by the tool that could be chosen but never should be chosen.

Every time we hire a new team member we'll need to "Jira has this option that you should never select, we'll show it to you and allow you to choose it, but don't".

I'll need to do this on every popup screen I have if is uses a custom field that must have a selection.  Right now it's just this 1 screen and field but I envision much more if we have customer support start creating tickets from customer call.
- Select Customer (just don't select "None")
- Select Region (just don't select "None")
- Select Rep (just don't select "None")
- Select Product Line (Just don't select "None")
Add many other screens and it just gets worse.

See where I'm going?  When I tell Jira users "it's not a fault in the product, it's how YOU work and think".

[Matt Parks]

As long as the field is required, they simply can't select 'None' as an option. All of the other hoops we're talking about are how to remove the 'None' option.

There are really four scenarios:

1. Field is not required. None is a viable option and should be available in the list.

2. Field must have a value at a particular point, post-creation. None is a viable option until that point is reached. Once a value has been entered, None can no longer be selected while the field must have a value.

3. Field must always have a value, but no default value is enforced. While on the Create screen, before the user has provided the default value, Jira has to provide some value for the field, which has to be None, since no default value for Jira to use has been provided. It will not be possible to leave None as the option when creating the issue since the field is required.

4. Field must always have a value and a default value is provided. None is no longer an option in the list.

In the first three scenarios, there are perfectly valid reasons why None could be a viable option.

Which of these scenarios are you running into? Not just in this particular situation, but going forward, it's something that you, as the admin, need to think about and plan for.

If you don't want people to select None, make the field required. If there are times when the field shouldn't be required, it's up to somebody (you, their leader, whoever) to explain to the end-user the reasons why the field is required at a particular point and why it isn't at others. If you can't explain the reasoning, that is not the fault of the tool.

Saying 'just don't select "None" should not be something that anyone does if they can't provide a reason why that makes sense to the end-user.

[Chuck Oleary]

I think we are going around in circles, I just do not see this as a behavioral problem.
To me it's like saying "we have this thing in the middle of software, don't worry about it, just work around it".
You are not explaining to me why it has to be there, how can I sell it to others who are and are not tech savvy? 

If I have many different screens with hundreds of options across a dozen different departments and every custom dropdown field has the selectable option of "None", however, never use it.

I have a Default Value set but it is not respected until I set the field as required?
So I have no ability to use the default value on dozens of single select dropdowns and screens unless I make them all required, when many will not be required.

[Matt Parks]

No, the default value is still honored even if the field is not required. It's just that the 'None' option will still be available in the drop-down list because, since the field is not required, it would be possible to have no value on the field (just as it would be possible to change to other values after the default value was set).

Regarding your first comment: If you never want people to use the None option, make the field required. If they try to create/update the issue with that field set to None, they will get a clear error and the update will fail.

I don't think I can explain any better as to why the None option has to exist. If my explanation isn't clear, I apologize.

[Chuck Oleary]

And when I make it required and they attempt to move a ticket from a Story to a Bug ticket type they are asked for a hold reason even if it's not on hold.  Is that also expected behavior?

[Matt Parks]

If you made the field required through a Field Configuration (and not a workflow transition, which would be better,but would require a plugin), and there are not separate Field Configurations for Stories and Bugs, yes, that would be expected

The solution to that would be to follow my previous suggestion about creating a new Field Configuration that only Bugs would use and then not have the field required in that configuration.