When I add "Resolution" to the edit screen I get presented with all the options (e.g. "Cannot reproduce", "Duplicate", etc.) but I don't get the Option for setting it to "Unresolved" (NULL in the Database).
Since the resolution field can be set manually, it can be set by mistake manually. Having no way of correcting this even for an administrator is strange to say the least. Having to modify workflows and so on is not exactly an easy way to fix a simple mistake!
There is a relatively easy hack with Chrome/FF I use on occasions when it happens:
<select class="...item should be selected.
Wow, a great work-around!!
This is either impressive, hilarious, or pathetic. Pick one.
Thx bro! Saved hours of wasted time!!
We had to shake our heads in disbelief that this is actually working xD
In step 5 you don't even have to change the text to "Unresolved" it's enough if you set the value of any option to "" and select/submit that one. I do it too often
Yes! To this hack...need to remove "selected="selected"" in the option of the value currently selected too.
Wow.. This is brilliant. Saved me from a massive headache.
Awesome hack, it solved my problem. Thanks for providing this solution.
In order to set the resolution to "Unresolved", you must clear the resolution field via post function. It is in the default JIRA reopen transition like Jamie said.
But, as the project manager, I want to set the resolution to Unresolved without using workflow. I'm simply clicking the Edit button and then my screen associated with editing the issue appears, and on it is the resolution field. I want Unresolved to be an option.
This seems like an oversight and we need it.
AGREEED ~ Kayen Maher
+4 This is ridiculous. Wasting hours of people's time is not the hallmark of project management. Or is it?
I have the same problem. In my case we had a Story which was included in a Sprint, in which we did not complete the story by sprints end. In this case, we close the story, set the resolution to "Not Completed" and clone it so that we can add the additional work in our next sprint (we don't want to move the Story, so as not to loose track of the time spent for the uncompleted sprint).
When it was cloned, it cloned the resolution as welll, which makes no sense if I can't manually change the resolution.
I can think of a dozen other scenarios, where someone may need to manually set to unresolved (without transitioning to another, which BTW adding these post transactions to the workflow is a pain when there are multiple transition states, whether you agree that there should be multiple states or not....). This does NOT feel very AGILE to me. Seeing lots of quirks like this throughout Jira.
+ Cannot edit any issue without having to speicify resolution status (still w.o. unresolved option)!
You generally need to pass the issue through a workflow function that clears the resolution. For example take a look at the "Reopen" transition in the default jira workflow.
Alternatively it can be done programatically.
The reason for this is that you generally only show the Resolution field on a screen on a transition where the issue is expected to be resolved, eg the Resolve transition. Setting it to null here doesn't make sense and should not be allowed.
I'm sorry, but I think that the question here makes perfect sense. We have the same problem, caused by a workflow (poorly implemented admittedly) causing a resolution to be set before the issue is resolved. These issues are "disappearing" from peoples "my current issues" type filters even though they haven't been completed. We need get all these issues back to being unresolved without having to move through the workflow.
If the workflow had been fully tested, before release, then maybe we wouldn't have this problem. But this is the real world and these mistakes are made, and we need obvious ways out of obvious problems we encounter.
Short of going into the backend database and manually changing this, there doesn't seem to be an answer to this.
I wasn't saying the question didn't make sense, just that allowing a null value in the picker generally does not make sense, that should be handled in a different transition. Although my post was over a year ago.
Script runner plugin has a built-in script that can fix this problem: https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-BulkFixResolutions
Congratulations ! I've have been given the wonderful job of being lost because an admin accidentally, thought he was helping some one by adding the resolution field to a screen. It defaulted a value when viewed. Now when some one opens the issue it defaults to a random unresolved value, (which is possibly 44 main thread issues) , no one can access them. I have no way of easily getting them revised to unresolved, and have spent 5 hours so far trying to figure out how to fix. And no, the reopen on the worflow doesn't update to unresolved. There may be a script fix, but not for the cloud/on-demand version.
A word of caution here. We had the problem that originally when we created issues, the Resolution field was not a Required field. Something changed and now when creating a new issue, Resolution is required. When you look at the configuration, it does not show it is Required.
We created an "Unresolved" resolution status and while searching for JIRA documentation to see how to make Resolution field not required during creation we have recently seen in the JIRA documentation that this is not recommended as it can cause problems because the status confuses the JIRA code that has an "Unresolved" status.
We almost proceeded with the same solution, luckily we "tripped" over the JIRA note stating that "Unresolved" status is reserved. We added "Reported" flag to be the default status on creation of a report.
Now we set our filter to find "Unresolved" and "Reported". Still sucks, but at least it gives us some measures to manage the bug status.
well, for one, Altassian should not allow administration to create a resolution of 'unresolved' that places a value in the DB when there already is a state of unresolved which is null.
The reason many people are asking to be able to do it manually is because they are in a position where gadgets using filter definitions are looking for the null setting rather than the custom resolution of 'unresolved' and have many Jira issues (1400 plus for me) in various projects with various workflows and you cannot do a bulk update to all these issues for the post function to clear the resolution.
This functionality allows a bulk update to the correct "unresolved": https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-BulkFixResolutions
We are on cloud.......
You'll need to create a transition that clears the resolution field in a post function. As for the DB, there is no state in the DB for unresolved. It is the fact the field is null that triggers the RED unresolved display in the UI. However, I agree, it would be nice if they disallowed creating a value of unresolved.
There is no way to clear the field from the edit screen. Unresolved means the field is empty. Only a post function can clear the field. The edit function will put something in it, even if it is just blanks. If you're lucky they are all in one or two statuses and you can update the workflow with a transition that only you can perform that clears the field and returns it to the same status. I've found setting the resolution at any point except at closing the issue leads to problems with the issue being ignored from then on. We used a 'Developer Resolution' field for the developer to mark before moving to testing to show they thought they had fixed it, but only at close would the Resolution field be set.
What state is the issue in where you want to reset the resolution? You should be transitioning the issue back to a previous state given the design of Jira's workflow mechanism.
Like from resolved to open state. That transition should be modified have the post function to clear the resolution field.
Otherwise add a new resolution value called unresolved. The resolution field will be closed but you can at least query to find those unresolved issues.