nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

David Aberdeen

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?

Accepted answers

Nic Brough -Adaptavist-

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

All comments

Bhushan Nagaraj2

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

Nic Brough -Adaptavist-

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.

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.

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.

David Aberdeen

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"!

Nic Brough -Adaptavist-

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.

Karie Kelly1

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.

Nic Brough -Adaptavist-

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.

David Aberdeen

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

David Aberdeen

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.

Jeannette Lamb

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.

Jeannette Lamb

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

Steve Mount

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.

Nic Brough -Adaptavist-

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.

Steve Mount

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.