I see defaulting to a level causing issues where we skip the triage step and everything is Medium whether or not that is appropriate. I would appreciate the option to default to null for projects with a triage process that relies on the accuracy of the priority field.

yes please, definitely need this feature. 

How do you block a priority value from being selected, thus forcing the user to pick another one?

https://getsupport.atlassian.com/browse/PS-121341

How is this not solved yet!?

Because there's literally no incentive for them to do so; they know everyone will keep using Jira regardless.

Although, that of course could change.

Not enough votes on the ticket, I guess?  

How is this not solved yet!?

I'm sad this still happens in various situations. I guess I'll have to make a "No Priority" priority and block folks from being able to make tickets with that priority. 🙈

With Jira today, there is literally a setting on priority schemes to say this scheme has no default, but it doesn't actually work.  This is no longer actually a suggestion request.  It is actually a broken feature in Jira.

This request will have its 15th birthday next year.  For a company that talks about trying to empower teams, it seems allowing a configuration where issues have to be given a user considered priority vs just getting a default and every issue and up the same (because people can't be forced to make a selection) is totally opposite what you claim to be providing to your users.

But this is the typical crappy consideration your users are accustomed to I guess.

Just wondering, how many votes are needed for this, to qualify Atlassian's feature/fix request.

A disappointing outcome. We have teams requesting this feature, but will now have to advise them that it will not be provided and they should consider alternative ways of working to accommodate.

If people not only complained but actually stopped using and buying their stuff, things would change. You continue using it, must be good enough for ya

This was created 09/Jul/2007 1:35 PM. So far no solutions. I'm giving up on it.

Hi here,

This issue is also relevant for other "native" fields on Jira CLOUD. And from what I know there is no existing workaround for Jira CLOUD as priority schemes do not exist at all for CLOUD

Have good day

Clement

I agree with the above comment. It would be useful to have an empty Priority field be allowed as the default value. Until then, the workaround I proposed serves the purpose for us.

IMHO, the above is not resolving the root cause, it is indeed a workaround and the value is not actually empty but with a string call "Not prioritised" or "none", with Jira itself setting the priority value to empty, it will then recognise it as empty value and force use to consciously select the actual priority instead. 

Hi all,

A solution that I implemented as a global Jira admin for a project team was the following:

1. Add new priority (with name "Not prioritized", description "Issue not prioritized by user", and icon URL [a black question mark with white background]).
2. Add a new priority scheme (with name "Priority scheme - not prioritized default").
3. Add a new priority (called it "Not prioritized").
4. Make the new priority the default priority.
5. Associate the new Priority scheme with the project of the team that asked for it.

While Jira doesn't let you set unique priority schemes per issue type (e.g. one for Project X Stories and another one for Project X Bugs), you arguably don't need the Priority field to show on the screens of all the issue types in the project.
 

In my case, majority of our ticket priority is set to Medium by default which is useless and frustrating, there were workaround but manual tasks, it has been really hard and not viable to keep reminding people to amend their ticket priority accordingly. By having an additional empty value with option to set it as default, sounds very much a simple effort to implement with great outcome, hope Atlassian will be kind enough to implement it.

For Cloud users, I can confirm that setting a "none" or "unspecified" default priority + a validator "Field Priority should be modified during the transition." does NOT work.

@Atlassian it would be nice to understand what are your plans on this. Last official answer if 4 years old and there's a significant number of requests/inputs here.

I'll admit again, though, all of these are work-arounds though.

@joel
I think I mentioned this in a sooner post, but we just created a default priority of "no priority selected".  There is a couple of options on what to do from there.  In our case, we have a some custom integrations to do the following:

• Jira tickets can be entered from confluence pages (especially used for our internally reported incidents which need a suggested priority).  Our integration from the marketplace allows us to set what options are available from the full set of options.  We mark this field as required, but ommit the submitter from being able to select "no priority selected".
• (push system) We use automation for Jira for many things, but one thing you can also do is send slack messages on certain events and conditions.  If needed you could set someone or a channel to get pinged when someone submits a ticket with the priority set to the default "no priority selected (with more constraints if desired).  This allows someone to be notified to follow up

• (pull system) Further more, we have a audit dashboard that looks for inconsistent states in Jira and call them out to be fixed via jql filters.  you could make a JQL filter that is present on one such dashboard (that someone could setup as their Jira homepage everytime they log in) to show tickets with "no priority selected" as set on a ticket.  This, again, allows the visibility for someone to follow up and get a priority assigned.

+1 This is still needed.

Yup. Ours is named "Unspecified" and has a transparent white little icon.

Matt Song - For the last couple of years, we've solved this by defining a priority called 'Not Prioritized' and setting that as the default (there's even an icon that's a circle with a dash in it that seems appropriate).

It works well enough to indicate when a ticket has not been explicitly prioritized.

+1 This is still needed. Anyone find a solution?

Same need.

I really don't understand how this can be so hard to implement. This is a common request on most of systems I've been using and developing and make so much sense.

+Vote!

12 years Gathering interest nice!

This would help our team from erroneously labeling new submissions

This would be very helpful for our team as well!

We need it badly! +1 for priority field being empty and mandatory for users to make a choice. 

l would like this feature to enable us to make this field required but force the user to make a decision.  With a default value the user doesn't have to choose and can save with the default value in the select list rather than actually selecting something. 

I would very much like this functionality to force user to set priority for each issue instead of using default priority

+1 for priority field being empty and mandatory for users to make a choice

I like this idea, and I like the corresponding bug reported in relation to Issue Type (JRASERVER-30620). They would allow administrators to force users to make decisions based on the information available to improve the quality and usefulness of the data in the issue logged.

This is even more misleading now that priority schemes are released...if you don't identify a default in your scheme, one would assume that means you want it to be empty, not that you don't mind if Jira picks a default for you.

Admittedly I'm just trying to make lemons into lemonade and would like the real solution too.  As stated above though, this will at least not give a real priority that is also the default (our was "low") to every ticket, which confuses everyone down stream about "which ones are really low, and which ones were just the default value that I need to talk to the reporter about a real priority".  That at least have a flag now for ones where the reporter did not set the priority value and can reach out about their thoughts on priority.  Not optimal, but at least gives us a chance of not having someone mark something as the default (which was low) and coming to us a week later saying it's the most important thing in the world and interrupting our sprint.

I am not in favour of the proposed workaround either. The ideal solution would be a mandatory Priority field that opens without value, and which requires users to make a deliberate choice...

We need the priority which it will be "None" and then user create issue it must choice priority (mandatory)

thanks for input. We will also go for a a "not set" default value. Our policy is that - not set - state is not allowed and thus we would like to tool enforce that. But in this case of possible invalid state over possible invalid value - ill take invalid state = default not set value

il look at the transitions thing also

Pffffft. I added an Unassigned value and set it as default. Tried to put a 'value must change' condition on the Create transition to New....it doesn't respect it. I guess it considers setting the default a change.

Although it may not solve all cases, we've added a default priority of "unassigned" or "not set" so at least the prioritizor of this ticket knows the requester didn't put in a priority when putting in the ticket.

im a bit surprised that a ticket system like Jira does not support this. Getting trustworthy prio on tickets is key.

@Sarathi - It seems that you actually have a Priority called "Not Prioritised" defined as the default value. In your case you only need to remove this defined value and need to set the priority to one of the remaining values.

Is there anymore progress on this?

I can make every other field with 'None' as a value a mandatory requirement for the user to complete on initial defect creation apart from 'Priority' which is an important field.  Although it adds the "required" asterisk it just doesn't do the "required" activity.

Do we have a solution for this ?

Setting Default Issue Type to "None" Ignored

We need this also, not sure why dose it have to have a default value.

Dear Team, 

could you set this suggestion? 

It will be cool, then we are setting js or workaround by transition.

Thank you. 

This looks like a bug as mentioned from previous comments. You can set the Priority field as required on field configurations and validator but can't set it to blank on purpose?

I also tried this workaround with no luck on the server installed version of the product. Would love to be able to remove the default. It causes people to leave it on the default (medium) instead of setting it to an appropriate level. Unfortunately without this feature working it means people put things in with invalid priority.

Hope this gets fixed soon.

Hmm, maybe it's a cloud thing

matt, thanks for chiming in! What I'm saying is that I did what you described and it doesn't have the effect you described.

In the config area, the Priorities screen, none of the priorities was marked as default. But when I create a new ticket, the priority dropdown is defaulting to P3 (which was not the most recently selected default).

FWIW, we're using the cloud instance, not hosted.

I guess your instance has chosen a default for the Priority. If you can't unselect the default you can try (in staging first): create a new Priority opion, make it default, delete the new Priority option. Now no option is default

I tried Matt Doar's workaround, and although the configuration screen showed no default, when I created a new ticket, the priority field pre-selected P3 (presumably the middle value of the select drop down?)

I think this workaround helps somewhat:

1. Create a new priority named "To Be Deleted"
2. Make it the default priority
3. Delete the new priority

There is now no default priority set. Then use a workflow validator to check on the Priority field so that the next time the issue changes status, a value will need to be chosen.

This feature is needed for sure because if a user finds this field filled in they may think it's the value that's supposed to be there. At the very least you could add "None" to the list or something similar.

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future.

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

We added a "Not Prioritized" priority, made it default. We have regular meetings (with key persons from different teams) to decide how to prioritize these and also change others too. That works well for us.

This would be important for us, as others have said.
We have a default value of TBD (To Be Decided).
Having a default value means users don't always think about the ranking and important issues may be overlooked for a time due to the issue not being reported as Critical or Major.

This issue is really important for us. Right now, 87% of our issues have "Major" priority (the default), and nobody can even estimate for how many of these the reporter actually chose this priority as opposed to not thinking of priorities at all!

We are using JIRA within Atlassian Cloud, so there is no workaround available for us. Introducing a different default priority would not help because people would forget to change it to a real one while creating the issue, and furthermore forget to change it afterwards. But even if they did, this creates extra work and much spam due to change e-mails.

This issue is important for us.
The user omit "to check" the correct priority for de task, in order to define the main activities to do, and that affects our metrics system too.
Help us.

14 months ago:

While we will not be addressing this feature right now, we plan to resolve several other top voted feature requests in the next 12 months, including: JRA-1558, JRA-3821, JRA-2703, JRA-7659.

JRA-3821:

In our March 2014 update, we stated that we expected to address this issue in the next 12 months. However, we continuously re-evaluate our roadmap, and at this time the work required for this issue has not been scheduled. Looking at our current priorities, we do not expect to work on this issue in the immediate future.

Unfortunately, the above solution is not available for "On demand" which is what we are evaluating. This is so fundamental that I cannot believe it cannot be done and does not even look like being implemented in the next 12 months. I just know that we are going to get a load of reports with the default value for priority. Really not good at all.

Yes!

I finally found a workaround for this. Its not perfect but it works.

I did it by installing Jira Workflow Toolbox. https://marketplace.atlassian.com/plugins/com.fca.jira.plugins.workflowToolbox.workflow-toolbox

1. Create a new priority. I called it "None" and had a big nice "stop-sign"-icon for it. Make it the default priority.
2. Go and modify your workflow. (administration -> issues -> workflow -> edit yours -> diagram).
3. click on the "create issue" transition. (the arrow going to your initial state).
4. click validators in the right column.
5. add validator
6. select "Validation based on regular experssion".
7. select priority as the field.
8. enter None in the "regular expression"-field. (or whatever you named your new priority)
9. check the "negate validation"-checkbox.
10. Type in a nice error message.
11. save and publish draft of the workflow.

What you have done is essentially created a new priority and made it default. You then created an validation rule to make sure that this new priority is not allowed to be selected for this transition.

So in practice, when someone creates a new issue, "None" is in the priority-dropdown. If they don't change it to another priority, they will get the error message that you set and the issue wont be created. Once they change the priority, the issue can be created.

You will be able to edit issues after they have been created and change back to the none-state.... we have permission that makes sure only developers can edit. Its not really an issue for us and this solution does what i wanted it to do.

Ditto to what Christopher said - if anyone has friends at Atlassian, rattle some bushes!

This is becoming a major issue for us, because users are leaving issues at the default priority instead of considering what their priority is. This means most issues end up having the same priority, making triage difficult.

Please implement this feature.

Please implement this feature. There are so many other products out there of lesser quality and lesser cost that have this feature. Why doesn't JIRA have this yet?

I forgot the "Attention: Sarcasm" sign here

More than 25000 customers but how many are reporting and following in here?
Currently, only 82 issues with votes > 100 and 23 with votes > 200 are listed as not resolved.
So, to me, >100 votes is fairly important.

I cite from atlassian homepage which might answer your question:

"When we make internal decisions we ask ourselves "how will this affect our customers?" If the answer is that it would 'screw' them, or make life more difficult, then we need to find a better way. We want the customer to respect us in the morning."

>100 votes is just a small percentage when you have > 25000 customers.

This is crazy. This ticket has been open for 6 YEARS. Is this ever going to be addressed?

I am also annoyed that this capability is not here... and when I look at how long it has been around, I am actually surprised.

I do not think it would take to much time to resolve, either.

For Atlassian:

One of the features of having a field required is that it requires you to actually do something.
If I have the field "State" required on a customer form, they must select a state to continue and they get some type of warning preventing them from continuing.
However, if I have a dropdown box list of states and the first state listed is (in alphabetical order) "Alabama"... guess what. Suddenly everyone is from friggin' Alabama. They don't have to think much in order to select the correct state.

Now, I wish human nature wasn't that way, but it is. And one of the things I generally like about Jira is it seems to take human nature into account. Well, not having this was a swing and a miss. Fortunately, you got it right with custom fields.

Can you make it right here. If it really is a big programming effort, please respond to that effect in this comment thread. Otherwise, please resolve this.

This lack of functionality actually breaks the tool in two ways: you cannot have "None" (or a null or empty value) for Priority, which would be useful in and of itself, but the tool also initially creates the ticket with no value for priority before forcing a default in the creation screen, rendering useless any applied "Field has been Modified" Validator, since the field has now been "modified" from a value that JIRA will not let you select in the first place.

Also, I do not believe that any of the workarounds are available to OnDemand clients, so it would be nice if this ticket was someday assigned and taken care of; I assume that the amount of time necessary to implement the change would be quite low.

A default value is for most users a reason to forgot to change it.

I would like to be able to set the default priority value to "None," so that users can select an appropriate value when the priority is known, but otherwise leave the field blank so we can sort using that null field.

Oh I see that is true! Sorry.

I've been using plugins for basic validation for so long I forgot how braindead the default JIRA validators are!

JIRA Suite Utilities plugin includes a condition called Value Field that works well for comparing any field to a text value (including "!=" and comparison to empty string for undefined values).

          <condition type="class">
            <arg name="comparisonType">1</arg>
            <arg name="fieldValue">Undefined Priority</arg>
            <arg name="class.name">com.googlecode.jsu.workflow.condition.ValueFieldCondition</arg>
            <arg name="conditionList">6</arg>
            <arg name="fieldsList">priority</arg>
          </condition>

And JIRA Workflow Toolbox plugin includes a "Compare two parsed texts" validator that can be used similarly but in the validation rather than condition phase.

        <validator name="" type="class">
          <arg name="leftTextExpression">%{00017}</arg>
          <arg name="failureMessage">You must set a priority.</arg>
          <arg name="class.name">com.fca.jira.plugins.workflowToolbox.ParsedTextsValidator</arg>
          <arg name="rightTextExpression">Undefined Priority</arg>
          <arg name="operator">!=</arg>
        </validator>

I tested both of these against a priority I set up whose value was the text "Undefined Priority" and they both worked well. We've been using both of these plugins for a long time with no problems (they're updated when JIRA is updates, they don't cause instability, they're easy to install, they're both plugin system 2 and managed by UPM). The first one is free and open source, the second one is paid but very cheap and supported by its author.

It does seem silly that we have to rely on plugin providers to give us such basic functionality in conditions/validators as "compare a field against a value".

To refute the above comment, this is still not possible, because there is no standard validator in JIRA that lets you check the value of a field. This means there's no way to tell if the priority value is "Priority Not Set" in any validator for any workflow. Otherwise, this would be a simple workaround.

IMO JIRA5 resolves this issue. JIRA5 properly renders the priority selector based on the configured default regardless of where that default falls in the order of options. Back in JIRA4 this was not the case for the sub-task quick-create form. So now you can make "Priority Not Set" one of your priorities, make it the default priority, and make it either your highest or lowest priority. And as mentioned you can set up workflow validators to make sure it is set before workflow progresses to certain steps.

Because some people will want the "undefined" priority to be the highest priority and others will want it to be the lowest in search results, I think this is a more flexible solution than allowing a true undefined value for priority.

This related issue is definitely resolved by JIRA5 - https://jira.atlassian.com/browse/JRA-23302

My team has found that having an 'Unknown' priority that is the default is very useful. I would suggest that Atlassian make this the standard behavior for JIRA. Often the person reporting the issue doesn't know what the priority is relative to everything else, and forcing them to make the decision doesn't make any sense. It's also useful for project leads to be able to set the issue priority to 'Unknown' when re-prioritizing issues to indicate that it needs to be reviewed.

If some users want to require the priority to be set at certain stages in a workflow, they can add validators to force it.

I successfully used the code that Martin Burton published here on 07/May/09. Now we want to upgrade to jira 5 and apparently the workaround doesn't work anymore. I notice that the format of the pre-installed priority-edit.vm has changed too. As I have no knowledge whatsoever of the language used here, I was wondering if anyone could create a new workaround. Thanks.

In my opinion this should be regarded as a defect. According to Atlassian much work has been put into the creation of the priority field. Users a "lazy". Sometimes you have to make them think before they do sth. Setting the priority of an issue would be sth. you should think about in advance...

I believe this is required missing functionality, especially when combined with Greenhopper.
We cannot use a custom field. Greenhopper shows the priority indicator icon. Using a custom field will reduce visibility of the Priority in this case.

I believe this is a defect, as well, and not an enhancement request. The Priority field should not be set to Major by default which JIRA does and there is no way to change that value.

Actually the coding given above would not solve the problem.
The default "NONE" priority should be there so that the reporter might mark it as NONE while creating, But the assignee must change the priority as the assignee is more educated about what the priority should be!
Thus if a defualt NONE is there, we can validate the priority at the resolution step to not be none. The assignee/PL must have to set the priority while resolving even if the reporter has marked it NONE/UNDEFINED
But the problem is that a priority type"NONE/UNDEFINED" if added,cannot be validated as it is also considered to be a "PRIORITY".Hence treating priority as a CUSTOM field can solve the problem.

But if we make a custom field now, HOW can i copy the priorities of EXISTING LOT of issues to my custom field.

I have tried the workaround suggested by Balarami. However the None option appears in the list when editing an issue. If selected the error is given, BUT the priority is then changed to Blocker. To overcome this I have changed the code to:

#controlHeader ($action $field.id $i18n.getText($field.nameKey) $fieldLayoutItem.required $displayParameters.get('noHeader'))

<select name="$field.id" id="$field.id">
#if ($displayParameters.displayNone)
<option value="">$i18n.getText("common.words.none")</option>
#end
#if ($req.getRequestURL().indexOf("create") != -1)
<option value="" selected>$i18n.getText("common.words.none")</option>
#end
#foreach ($pr in $priorities)
#set ($iconurl = $pr.iconUrl)
#if ($iconurl.startsWith('http://') || $iconurl.startsWith('https://'))
#set ($iconurl = $pr.getIconUrl())
#else
#set ($iconurl = "${req.getContextPath()}${iconurl}")
#end
<option value="$!pr.getId()" class="imagebacked" style="background-image: url(${iconurl});"
#if ($priority && $pr.getId() && ($priority == $pr.getId()) && ($req.getRequestURL().indexOf("create") == -1) )selected#end
>$textutils.htmlEncode($pr.getNameTranslation())</option>
#end
</select>

#localHelp ('issue.field.priority' 'PriorityLevels')

#controlFooter ($action $fieldLayoutItem.getFieldDescription() $displayParameters.get('noHeader'))

This is a big deal to us as well. We are actually in the process of evaluating jira and i am surprised this is not supported. This is very basic that is supported by any other issue tracking system that I can think of. Too often people miss filling out fields unless you automatically require them.

Somebody please reply if any one has used it??

Fixed this problem to Have None in the option list and the user cannot select None as a value.

if the user selects the None he will get an error as 'The priority selected is invalid.'

Steps to do:

Backup the original priority-edit.vm some where.. to be safe.

Stop service

Please replace the attathced priority-edit.vm with the one in

\atlassian-jira\WEB-INF\classes\templates\jira\issue\field

Start Service

Try this and let me know if it works?

People often ignore defaults.

If I set default to

Blocker : I've lost lots of time investigating non-issues
Trivial : I've lost some major issues
Major : slightly better but still contains worst elements of both previous approaches

Removing the default and requiring the field would mean that people actually have to THINK about the impact of an issue and MAKE A DECISION of what the priority should be.

Inter alia this means we can find people who whine, people who are clueless...and 'educate' them.

I agree with the above statements that there should be a "None" value for Priority similar to custom fields.

I tried implementing the changes mike suggested, with the built-in JIRA workflow options.

I added a default priority of 'None', and using a condition it is possible to prevent a transition from displaying when the priotiy is set to none. It does not appear conditions are evaluated during issue creation.

What this really needs is a validator to ensure a field matches a particular value. That is not included with JIRA and I did not see that in the plugin library. Even if that exists it would still need to be included in every single transition to ensure the priority field is not tampered with. Even then, it does not prevent someone from editing the priority field beteween transitions - which will tamper with reports. (Even if done unintentionally, of course). Even if all those problems are ignored a validator would still not necessary prevent someone from using the 'None' priority during issue creation unless it is possible to have the validator execute at that step.

All in all, the priority field really should work like any custom select list field and simply require a user to actually select a value rather then prepopulate it.

I was unable to get any help with editing the velocity plugin when I originally posted in the dev forum. I'm surprised this isn't an issue for more people.

I had added a 'None' value however that didn't encourage people to pick a value. Everybody just left it as none. There are validators that can determine a field is != a particular value.

Have you tried adding a vaildator during issue creation? This would involve editing the XML file which I do for most workflows already so that isn't a problem, but I haven't tried putting a validator during the issue create block.

This is a problem for us as well. Users are dumb, you cannot trust them to read every field.

However is it possible to add to the priority list? If so you might be able to do is add a "bogus" priority to the list, set that as the default. Then use workflow validation to not allow the issue to be added until a real priority is selected.