Editing an issue changes it to "Fixed". How do I stop this?

If I create an issue, then edit it to change the description, it gets marked as resolved, and from then on, is shown with the issue name in strikeout font. The only way to get it back is to change the task to "Done", and then "Reopen" it, thereby clearing the resolution field by the workflow.

The simple solution is to make sure the Edit Issue screen is always in a custom view, and Resolution is not shown. However, I have my custom edit issue view set up to only display the basic data that I mostly change. If I want to change something else, then I use the "Configure Fields" button to show all fields, and make my change in the full dataset. Problem is, if the Resolution field is shown, then it has a mandatory value, and "Unresolved" is not one of the options. So, to edit any fields without also applying a resolution, I have to manually configure the custom fields. I can't just select all fields and change the ones I want, and leave custom fields setup with my nice simple dataset.

I have searched and found a few questions like this, but I couldn't find an answer anywhere. There doesn't seem to be a way to stop the Resolution from taking on it's mandatory default when other fields are editing, and Atlassian seem reluctant to allow "Unresolved" as a manually set option, even though all issues are created in this state, and all I want to do is leave it there while I change other data. I can remove the Resolution from the default edit issue screen. Is this the best solution, removing my ability to edit the Resolution altogether, and leave it to the workflow to set the resolution?

5 answers

1 accepted

Accepted Answer
7 votes

You have pretty much answered your own question.

If resolution is placed on an a screen and the screen is used for any update (create, edit or transition), then the resolution will be set to something.

This is by design, and it's probably tied into Jira's weakness when it comes to mandatory fields where they are either mandatory or optional for the entire lifecycle.

In a simple world, an issue should ideally go through: Created -> worked on -> closed. As you go from worked on to closed, you want to record why, and make that mandatory. As Jira can't do this, the resolution field is a bit of a bodge - it's coded to take a value as soon as it's used, with no option to blank it.

So, as you've already noted, the fix is to remove it from all screens and use it as designed - only on "we are done with this issue" transition screens.

This works for most people, because in the overwhelming majority of cases, you don't want a resolution until it's fixed, and if it's fixed, then editing it works. You just have to bear all of this in mind when you're working on workflows so that you remember to set/clear it on the right transitions, and not put the field on edit screens.

If you do need to edit resolution, one trick is to have an edit transition that goes back to the same status and goes through a screen that does include it.

Personally, I think the behaviour of mandatory/optional fields is far too weak in Jira and needs some love from the designers and developers, and the way resolution is used to decide a generalised open/closed status is fundamentally wrong (it was ok in Jira 1, weak in 2, and wrong from 3+), but that's another discussion...

Yes, I struggled with this for a day or so, and came up with my own answer to remove Resolution from the edit screen. My thought is that it should not be on the default edit screen if it behaves in this way.

As far as the data model is concerned, Resolution should not be mandatory in the database and edit screens, but should be set by the workflow, and may be defined as mandatory by the workflow, rather than the editing screen. After all, why should an edit screen define something to be mandatory when it has quite a defined meaning to a value of "Unresolved"!

It's not on the edit screen by default, only the resolve screen

The problem about mandatory fields and how they're defined is quite a wide ranging one. Short answer is it should be defined by end-users to match their processes, not by a flag that is all or nothing.

Hmm, considering this is a new install of Jira, and I didn't know how to configure what fields would appear on the edit screen until I had this problem, I think that my install did indeed have it on the default edit screen. But maybe that's only for some setups. Maybe there are other setups for Jira where it is not on there by default. Anyway, I've removed it from my edit screen now, so that even when I select "All fields", the resolution is still not there. That's a 'good enough' solution for me.

I totally agree with your comment about 'mandatory fields'.

Make sure that your field configuration for the project doesn't show Resolution as a required field.

In our instances, we have the Resolution fields on screens, but it is never required, except when I put a validator on it for the transition.

That's not the problem. The problem is that when you put the field on an update screen, the resolution is set, even when it's not needed.

How can I change Resolution to a non-required field on the default edit screen? I can find the selection for which fields go onto the screen, but I can't find anything which says mandatory or not.

We've been using jira for about 2.5 years and I have never seen this problem until just now. I have an issue in "open" status. When I edited it, the resolution field was automatically set to "fixed". I did not perform any workflow transitions.

What is the recommended solution? Remove the resolution field from all screens? That isn't really acceptable because we have multiple projects running with different workflows. all of the workflows in use don't utilize a "Resolve" screen with Resolution as a mandatory field.

When I remove Resolution from the default screen, it still appears when I view my issue but it is no longer editable.

It's exactly the same answer that was marked correct earlier. Please re-read that, it explains what you're seeing, and gives you the fix.

I did remove the Resolution field from my Edit screen which is the default screen configuration. As I mentioned above, When I remove Resolution from the default screen, it still appears when I view my issue but it is no longer editable.

1. Will this resolve the issue going forward, i.e. only with new issues that are created and edited?

2. If so, how can I remove the resolution = "Fixed" from my existing issue?

I also don't understand why we never saw this issue occur until now. We are running JIRA 6.0.8. We have been able to edit Resolutions in the past, after transition to "Resolved".

Thank you.

Ok.

1. Yes - this will prevent the resolution being incorrectly set in the future, but it will not change existing broken issues

2. Edit the workflow. You can add "clear resolution" to transitions into Open or Reopened and push issues through them, or even have "looped housekeeping" transtions - e.g. from "open" to "open", with "clear resolution" as a post-function, and a condition that says "only jira admins". Bulk edit allows for bulk transition.

The reason you haven't seen the issue before is that your admins had not added it to the "edit" screen before.

I am currently facing this issue though do not have Resolution on the edit screen, it used to be there and I removed it following the advice on this blog but the resolution is still set could this be a case where resolution has been set to required? and is being added regardless of it being shown on the edit screen.

No, the required flag won't do this.

The only way to set resolution from the edit action is to have it on the edit screen, or have a "listener" that listens for "issue updated" and changes the issue.

Is it defintely the "edit" action doing this? Not a workflow transition? (Transitions can have post-functions that set it as well)

Could you show us the screen and the history of an issue - the history should record when the resolution is being changed.

Hi David,

Do you have any plugins installed (listeners specifically)? Go to Administration -> System -> Listeners and check if you have any listeners installed.

Thank you

Bhushan

Thanks! I created a global transtion to "clear resolution" which works great.

Surprised to see that this is something that has not been resolved yet, other than users creating a work around! In our instance, all tickets are created in a status=triage. Is it not possible to clear the resolution field at the triage status? So, if a task/bug that was once resolved is reopened, it will open back up in Triage status and will clear the resolution field.

Resolved what?

In your case, you're opening issues with "status = triage".  You've built a workflow that sets that status.  It has nothing to do with the resolution.  I'd guess that you've also put the resolution on the "create issue" screen.  Which is "fixed" by, well, not having it on the screen.  And then, when you re-open an issue, as you'll find is documented everywhere, your workflow should include "clear resolution" as a post-function.

 

Very new to JIRA...with zero training, so bare with me. I didn't build any of the workflows, the individual that did is no longer here...I've been tasked with "figuring it out and making it better" so I'm limping along.

The resolution field it not in the create screen, so we only see the issue when an issue that was once resolved is reopened. For a few days, I did have the resolution field editable on the default view, which I found that whenever I updated the Team on that issue, it also changed the resolution to Fixed which is what is first in the list in the option box. So, unfortunately at the moment, I have at least one Fix Version with a couple dozen tasks that are now in an Available status and yet show a resolution of 'fixed' since the reporter forgot to assign a team to the tasks and each issue was edited after it was created.

I'll have to read up on adding a post-function to the workflow. That makes sense. Thanks for your help.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Sep 18, 2018 in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

23,358 views 2 7
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you