How to reset a resolution to unresolved?

[Gary Kumfert]

I edited the title of an issue and I think it set the resolution to FIXED as a side-effect. I blame resolution being a required field in the edit dialog, and not offering to perpetuate the unresolved state.

I read this post looking for a solution: https://answers.atlassian.com/questions/1765/how-do-i-set-the-resolution-of-an-issue-to-unresolved ...but it wasn't very helpful. I tried closing and reopening the issue, but that didn't help. I am loathe to invest the effort into understanding the whole post function discussion... it seems geared for setting up a workflow instead of just fixing a bad field.

Can someone please just provide a step-by-step to set this one field on one instance?

[Joe Pitt]

The resolution should never be on ANY screen except a transition screen presented when you want it set. It is ALWAYS required whenever available for update. To clear it you need to run the issue through a transition with a post function to CLEAR the field. The UNRESOLVED shown in red really means it is null.

[Ory Zaidenvorm]

Thanks! I was really scratching my head about this one and was about to open a support request when I saw your answer -  solved my issue!

It really is completely un-intuitive and also not mentioned in the related documentation.

[vasavi kakkat]

Thanks Joseph!

[Joe Pitt]

If my answer solved the problem please mark it as accepted

[Joe Pitt]

The 'unresolved' state is triggered by the field being empty in the database. You need to pass the issue through a transition that uses the clear the field post function on it. The resolved field should never be on screen except the transition screen shown when you are in a step in the workflow where it must be set. It will automatically appear on the issue screen.

[Nic Brough -Adaptavist-]

Resolution is an unusual field in that it is only expected to be placed on screens that are used in transtions that end in a status that you want to count as "issue is done with". Exactly as Joe says, you must not place it on any other edit/update screens, otherwise it will be set accidentally.

[peterschueller]

Maybe the system should warn about this. Or permit to "unset" the field if it is on a screen. Both would make the lives of users much better.

[Nic Brough -Adaptavist-]

No, it should not be blankable.  It's also hard to know where exactly to put such a warning.

Personally, I'd prefer to throw away the field and base the "open or closed" question on something else, then this problem would go away.

[Intendencia de Montevideo]

https://confluence.atlassian.com/jirakb/how-to-clear-the-resolution-field-when-the-issue-is-reopened-648381467.html

[Terry Heinel]

Yesterday I found a simple solution to this that worked for me.

This is basically covered above by @Nic Brough [Adaptavist] in JIRA speak (not a criticism) as  'Push them back through the workflow so that a "reopen" transition somewhere blanks it out'.

On a Kanban board I moved the trouble issue back to the "To Do" column and it reset the resolution to "Unresolved".

I would testify in court that I've tried this several times before and it didn't work but that may have been on an Agile board.

[Dave Campbell]

Yes this worked for me as well.  Simply change the status of the item to In progress and then put back to Not Done and the resolution resets to Null or Unresolved.

I cannot find where unresolved is set however as it does not appear in the view resolutions screen: Issues > View Resolutions?

[Joe Pitt]

The reopen works on the default workflow BECAUSE it clears the resolution in a post function. If you don't use the default workflow you need to add your own post function to clear the resolution field. 

[pjuska01]

Gary - Same issue here. And similarly I am hesistant to engage in post-function processing.

This seems to me a major Jira limitation. If adding the field to the edit screen is going to wreak havoc, then adding the field to the edit screen should be disallowed.

I've since reverted the change, but for the tickets that were marked with a resolution during that timeframe, I have no recourse to "nullify" the errant tickets.

As a result, tickets which are assigned to developers, architects and techincal resources are not surfacing in their "Assigned to Me" dashboard, and work is being missed.

Would love to see Atlassian put serious effort towards addressing what many folks have discovered to be an egregious pitfall ... easy to fall into, difficult to get out of.

Gary - please let us know if you come across a straightforward solution.

[Nic Brough -Adaptavist-]

The solution for fixing your damaged issues are

• Push them back through the workflow so that a "reopen" transition somewhere blanks it out
• Add transitions to your workflow designed to fix it (you can do this in draft mode. And remove them after you've undone the damage)
• (last resort because you need Jira offline, backed up, the backup proven, reindexing afterwards) SQL

It might seem like a limitation, but it begs the question "why are you editing a resolution, when the fact it's resolved means you don't care any more?"

[Gary Kumfert]

Nic,

Users are falible. We "fat-finger" things and expect "undo" buttons to fix our mistakes.

[Nic Brough -Adaptavist-]

I know.

But "undo" is a luxury, and should be unneccesary. The way Jira handles resolution was suitable in version 1 and arguably 2, but it's not worked well since version 3. It needs to change.

But this is the way it is now, and this is how you have to deal with it. Until Atlassian grasp that nettle and fix the way resolution/done/open/closed works properly.

[Ben Ellis]

"an egregious pitfall ... easy to fall into, difficult to get out of" -- totally agree. This shouldn't require so much work to undo. To date this issue is my biggest disappointment with Jira.

[Terry Heinel]

It's 2016 and this is still a problem. This field should really be editable. This causes confusion and a lot of wasted time trying to correct it.

[Nic Brough -Adaptavist-]

It does.  I'd junk the "resolution" approach completely and fix it properly myself.  But it's deeply ingrained in JIRA and apparently the Atlassian psyche.

If you have the script runner add-on, there's a canned script for fixing the issues that got broken by inappropriate usage of the field though.

[Vala]

Undo shouldn't be a luxury! It's a standard part of workflows designed for human beings to use.

I work in a team where we don't have a Jira admin and the workflow doesn't include a transition that clears the resolution flag. So as far as I can tell I can raise a ticket with IT and try to persuade them that it's worth their time to help sort this out or just have broken tickets that won't be tracked correctly go through the board.

This is disappointingly poor, and this issue has been around for 7 years.

[Nic Brough -Adaptavist-]

Mmm, not for a lot of processes it's not.  If your humans are making that mistake a lot, then there's something wrong with the process or their training.  Even if they're not, there should be a route to correcting it, but for a lot of processes, that should be a pain, in order to help them learn to stop making mistakes with significant impacts.

How, for example, would you make me undo reading the email that the process of creating your comment caused?  You can't undo that.

[Vala]

Ok. Tell me how undoing reading an email is in the slightest way similar to clearing a property on a Jira ticket and I'll concede you have a point.

[Nic Brough -Adaptavist-]

Reading an email was a simplification, but it proves the point that "undo" is not appropriate for some actions.  As you can't undo my reading, you make a right mess if you undo what triggered it.

When you change the status (and that's the only time you should change a resolution) is not just "clearing a property".  You are fundamentally changing what the issue is presenting to your users, and the action of changing status can have a lot of knock-on effects.  Historical reporting, notifications going out, builds being triggered, messages going out to channels, and and and - all affected by the change. 

A simple edit is arguable, but they can also matter - it depends on the field being changed.   I certainly believe in undo before the change has triggered anything (like while you're editing a doc or even field content), but in this case, you've triggered changes that you can't undo.

[Vala]

That there exist cases where undo is impossible doesn't change anything in this case. It's an irrelevant distraction. I'm clearly not asking for a way to ensure 100% that every single action that may or may not have occurred as a result of marking something as resolved in every possible edge-case across all possible Jira flows should be undone perfectly. That would be nice, and frankly I think it makes sense to have that for a period of time in any case (e.g. 20 seconds to undo).

I'm asking for the field value to be cleared and for the ticket to still count as open for the sake of reporting. If this is as impossible as making a person unread content then Jira is incredibly badly designed.

We live in a world where the most popular e-mail clients are able to undo the sending of an e-mail and it sounds like you're arguing that the fact that we have a situation where someone accidentally moving a ticket to the wrong column means it's perfectly fine that it's not only complicated, but that it even requires admin access to undo a simple drag-and-drop mistake. How is that an acceptable user experience? And that's before getting in to how this issue happened for us where someone cloned a closed ticket and the clone kept the resolved flag (which makes even less sense in my view).

Sure, I'm not oblivious to Jira having complex requirements, but the feature that was asked for here isn't some fringe edge case that it's fine to ignore because people somehow shouldn't be making mistakes or it's fine to just punish users for making mistakes (as you imply by saying it "should be a pain").

The lack of a way to do this is breaking reporting for this ticket already. Even if there was a risk that removing the flag might be an issue in some edge cases it's of little concern to us with the way we use Jira anyway.

[Xiang Huang]

add a post function trigger and choose update a single field value

choose Resolution field and select "None" in the filed value. 

[Joe Pitt]

Unresolved indicates the field in the database is NULL. You need to go through a transition with a post function to clear (set back to NULL) the field.

[George Barker]

Cycling back through the workflow does not allow me to set the resolution to "Unresolved".  That is not an option in the drop down.  And I cannot clear the resolution - it's a required field.  So what to do?  This ticket was abandoned in error and needs to be brought back.  I cannot use the SQL option because I use Jira on demand.