@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.

Created:09/Jul/2007 1:35 PM - 10 years !! really ??? 

Simply put - how do I ensure someone puts one of the 3 Priority levels we have ?

The * appears but one can leave it as Not Prioritised ! ? 

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.

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.

Anton,

Thank you for your suggestion. Unfortunately this is not suitable for me as I would lose all the built-in priority work that JIRA already uses, such as displaying open issues by priority on the project panes.

I realize there are thousands of open improvements and enhancements, and I have voted on several that I would love to see, but I do not understand why this is not a bug. Every custom field, and all other JIRA built-in fields (components, fix version, affects version), when marked as required, will actually require the user to pick a value. It is only priority that functions differently. Even when no priorities are actually selected as the default (by creating a new priority, setting it as default, then deleting it) a priority is still automatically selected.

I posted a request in the dev forum about editing the velocity pages:
http://forums.atlassian.com/thread.jspa?threadID=19222

If that is the only workaround for this bug, I don't mind implementing it. But at the moment, there doesn't seem to be any workaround. If, with the help of the dev forums, I find a workaround I will link it here.

Thanks,
Eric

Eric,

Is using a select list custom field and then hiding the priority a possible work around?

With every release, our biggest challenge is to deliver as much value as we can. There are a lot of open requests and improvements for JIRA and therefore it is very difficult for us to address them all.

At the moment this issue is not scheduled and there are no current plans for its implementation. However, I hope that using a custom field could really help.

Cheers,
Anton

I opened this ticket with support last week, (JSP-14551 for Atlassian folks). I would mark this as a defect rather then an improvement, but regardless I believe this needs to be fixed.

I've been looking around and haven't seen many other users complaining about this, although from my point of view having a default priority is almost the same as having no priority. We have our default priority of Major, the third of five values. As a result, the overwhelming number of issues have a major priority, as most people do not change the value.

It must be possible to force a user to pick a priority, just like any custom field.