|
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,
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: 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, 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. 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. 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 agree with the above statements that there should be a "None" value for Priority similar to custom fields.
People often ignore defaults.
If I set default to Blocker : I've lost lots of time investigating non-issues 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. |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Allow 'No default' for Priority
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.