How do I set the resolution of an issue to "Unresolved"?

[Michael Postmann]

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

[Staffan Nilsson · Accepted solution]

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!

[Attila Fulop]

There is a relatively easy hack with Chrome/FF I use on occasions when it happens:

1. On the Issue view select the resolution field so that it's dropdown becomes visible
2. Right click on the dropdown and select the Inspect Element menu option:
    image2016-5-2 11:46:24.png
3. The Inspector pane on the bottom of your browser is now visible, and the <select class="... item should be selected.
4. Right click on the item and choose "Edit as HTML":
   image2016-5-2 11:48:15.png 
5. Add this option manually before the first <option>... tag: <option value="">Unresolved</option>
   image2016-5-2 11:49:40.png 
6. Hit CTRL+ENTER
7. Go back to the dropdown and select Unresolved:
   image2016-5-2 11:50:24.png 
8. Press the check mark to save, and there you go!

[ALittleDiff]

Wow, a great work-around!!

[Angel Cervera Claudio]

Good hacking! 

[Terris Linenbach]

This is either impressive, hilarious, or pathetic. Pick one.

[David Schruf]

Thx bro! Saved hours of wasted time!!

We had to shake our heads in disbelief that this is actually working xD

[Attila Fulop]

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 

[Ed Nystrom]

Yes!  To this hack...need to remove "selected="selected"" in the option of the value currently selected too.

[Kusala]

Wow.. This is brilliant. Saved me from a massive headache.

[Deleted user]

Awesome hack, it solved my problem. Thanks for providing this solution. 

[Seo Yongshik]

Awesome !!

[Kathy Barton]

BRILLIANT, LIFE-CHANGING HACK! TY!!!!!!!!!

[Craig]

Attila Fulop's solution is the easiest and works like a charm! (Just set the value of the selected option to "".) Also works in IE/Edge using F12.

[Balu Ertl]

Confirmed, it works properly, we used also many times as well. However, unfortunately, it seems like finally Jira developers protected their forms with some back-end validation in the new UI being rolled out in Autumn 2017. So this DOM hacking technique does not work for me any more.

[Nabil Assi]

This is brilliant and saves time in modifying workflows or re-do traistions to fix human errors.

Thank you Attila

[Nic Brough -Adaptavist-]

Except that it requires the resolution field to be on the edit screen.

Which you should not do, and is one of the things that gets you into this mess in the first place.

[JamieA]

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.

[Harvey Moore]

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.

[JamieA]

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

[Jason Ashley]

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.

[jo astley]

I have set a reopen transition and still the only options are 'wont fix', 'duplicate'...etc which are all the options for when you do the close transition. With the close transition the only ones which work are 'wont fix' and 'done' which also is not helpful. I need to find a way that all options work and also to include a unresolved option for the reopen transition. Any ideas? Thanks

[Edwin Chan]

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.

[Corey_Young]

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.

[Ted Hayes]

Absolutely agreed.

[Ghosts Are Real]

AGREEED ~ Kayen Maher

[Edward Skrod]

Absolutely agree.

[Steve Giacobbo]

+3

[Peter Boling]

+4 This is ridiculous.  Wasting hours of people's time is not the hallmark of project management.  Or is it?

[Savneet Singh]

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.  

[Clement Santander]

+5

+ Cannot edit any issue without having to speicify resolution status (still w.o. unresolved option)!

[Niles Broadhurst]

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.

[JamieA]

This functionality allows a bulk update to the correct "unresolved": https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-BulkFixResolutions

[Niles Broadhurst]

We are on cloud.......

[Joe Pitt]

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.

[Devina Allen]

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.

[Slavek Krzesinski]

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.

[Norman Abramovitz]

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.

[iQtransit Site Admin]

We had a few hundred of these, so I needed something I could just click within the page.

I was able to get this working using a bookmarklet. If you are familiar with a bookmarklet, you can use the code here: https://gist.github.com/cdalsass/85f78116f2558036291a5c532560c9d4

Or see a simple explanation here http://www.iqtransit.com/blog/jira-mark-resolution-unresolved-without-workflow/

[Anton Ukhanev]

Nice! Looks good. Will try it next time.

[Joe Pitt]

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.