nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What's in a word? How 'None' became so complicated

Rina Nir

I frequently work with teams who want to expand their use of Jira beyond the dev people. Are these non-pure-dev scenarios why 'None' is so contagious in my projects? Or is it something else? I am not sure, but this is what happens:

We define a custom field with a single or multi select option. For example:

Field name: 'Customer impact'
Options:
- No impact
- Downtime
- Change in functionality

So far, it is simple.

Now, when the field value is not set, assuming we opt to see the field when it's empty, Jira will show the value as 'None'.

But what does 'Customer impact = None' actually mean?

You see the problem. Someone who is not a Jira aficionado will think that there is no Customer Impact. Which is not correct.

So, to circumvent this, people want to set a default value 'Not evaluated' instead of leaving this empty.

The next thing is that we need to condition and validate at different transitions that the field is set. Which becomes much more complex because the system always sets the field to its default value instead of leaving it empty. Creating a more complex configuration then what we could have had.

Have you run into these contemplations? How do you weight the tradeoff and what do you eventually do in these scenarios?

Edit 18-Jan-2025
If you are finding this issue frustrating please vote on this JRACLOUD issue: https://jira.atlassian.com/browse/JRACLOUD-7320

Unbelievably this is an issue from 2005. At the moment, it does not have ton of votes, so- please vote this up. Perhaps we can make change happen

Comments

Dave Meredith

I've often though this. A blank field is actually more informative... It's clear that the field is empty.

I'm currently looking at:

"Change Risk = None"
which is more misleading that just having
"Chang Risk = "

If there is a NEED for placeholder text for some reason why can't it be "Unset" or "EMPTY"?

I was just poking around with translation options but I don't think there is a configurable option to make this less misleading.

Aaron Morris_49u8f7

I've encountered this problem many times over the years and have tried all the things you described.

So far, my preferred (least bad 😆) solution is to validate the field on workflow transitions without setting a default value first. That keeps the workflow logic a little cleaner, and the problem of 'Customer Impact = None' (for example) is short-lived until the issue is transitioned.

That said, I've long wished that Jira would display something like 'Empty' or 'No value' instead of 'None'.

Rune Rasmussen

When I've run into this my stance has so far been that, if a field has a value it has been set actively, and someone has had a look at the Issue and with an active opinion or knowledge decided that the field value should be set to whatever it's set as.

So if Customer Impact was set to None, I would expect that someone with knowledge, an opinion, and mandate, has actively set it based on the content of the Issue, and as such decided that there is no customer impact.

I have been explaining to the user(s) this, and that how when a field does not have a value it is "Customer Impact" IS EMPTY rather than "Customer Impact" = None.

I would also argue against using "Not evaluated" as an analogy for the field not having a value set.
Sure, it can be done, and you can work around it with your situation of Workflow conditions or validations, but it's really a slippery slope and adds undue complexity that could have been avoided if the users had a better knowledge or understanding of JQL.

Also, pr. my stance on "if it has a value it was intentional" then the field being empty means the same as it having the value of Not evaluated, making it duplicate and unnecessary.

And with all that, it would be nice if the descriptive grayed out text wasn't the word "None", but something else like "Empty" or "No value", like @Aaron Morris mentioned, or maybe even just not have a text.
Maybe just have a outline around the field to indicate that there is a field here and it has no current value.

Michiel Schuijer_jlry2w

It is a familiar topic that I have had endless discussions about throughout the years.

My suggestion would be to first create a suggestion with Atlassian, to do as mentioned in some of the replies to your post: ask to change the text to something other than "None".

Atlassian being on the verge of renaming "Issue" to "Work" (another one of those hot topics over the years), they may as well address this topic as well!

Your current solution, with a default value set seems most used in environments I worked, but can give challenges down the road, like the ones you described and with reporting, but it is my personal preference of the available options, because it is the least problematic for cases where people mistake the non-value for "None" value

Educating people, creating clear documentation for the project and adding a description to the field are things that can help avoid mistakes with it.

Rina Nir

@Michiel Schuijer

I did as you suggested and raise a support ticket with Atlassian. Once there is an issue key I'll share so we can vote.

Thanks for suggesting

Rina Nir

@Dave Meredith @Rune Rasmussen @Michiel Schuijer @Aaron Morris

Atlassian support found an existing issue on this (from 2005!!).

Please vote on this JRACLOUD issue: https://jira.atlassian.com/browse/JRACLOUD-7320

At the moment, it does not have ton of votes, so- please vote this up and ask your friend too. Perhaps we can make change happen

Ahmud Auleear

Hey @Rina Nir

Thank you for sharing your use case and feedback!

I’m a product manager for the Issue View and have the "none" values on my radar. I’d love to connect and discuss further. If you’re open to a call, please feel free to schedule a time that works for you through my Calendly link.

Looking forward to hearing from you!

Thanks Ahmud

Michiel Schuijer_jlry2w

Good find! I voted for it.

Crystelle S

A bit late, I will say I am old enough to remember the hot debate on the resolution field - where being empty was switched out to 'Unresolved'. So at that particular time, I remember people feeling strongly that an empty field was confusing. I wonder if they would move to that along these lines as well.

Michiel Schuijer_jlry2w

Similar, indeed, but having a value in that field will mark it as resolved, while having no value will consider it unresolved, so it can be trickier to manage properly.

I've seen pollution concerning this field in combination with with workflow delegation. Workflow delegation allows project admins to modify workflows, when the workflow is dedicated to one project only. While this scenario allows project admins to modify a workflow, they often miss/forget to set the resolution, and aren't allowed to create post-actions on workflows to do it automatically, often resulting in issues not having a resolution set even though they have a status from the "Done" category.

I'm not sure if this is behaves the exact way I described, though, as in my current company we don't allow project admins to edit workflows, mostly because of issues like this.

Josh McManus

Oh man, this infected our system in a very weird way. Somehow at some point in the past someone thought they needed to add a resolution of "unresolved" to our resolution list. Now we have both "Unresolved" = EMPTY and "Unresolved" = Unresolved. Fun times!

Josh McManus

Voted! It would even be more consistent if they went with EMPTY since it's what is used in JQL for that very result.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

custom-field

jira-cloud