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).
There is a relatively easy hack with Chrome/FF I use on occasions when it happens:
<select class="...item should be selected.
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.
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.
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.
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.
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
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.
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.
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.
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.
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/
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.
...connector settings, you'll see something like: <Connector SSLEnabled="true" if you don't see a line that says "ciphers=".....", you may have a problem. How to fix it? So you got a B on your...
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot