Open issues are appearing with a strike through on the agile and sprint boards

[rebekah]

Hi There,

My open issues are appearing with a strike through on the agile and sprint boards. Each issues "Resolution" state is listed as "unresolved". How do I remove the strike through? 

rebs

[Nic Brough -Adaptavist- · Accepted solution]

Two things - remove the data that breaks JIRA, then repair the broken ones.

1.  You have almost certainly broken your JIRA by adding "unresolved" as a resolution.  Change it to another name like "do not use this resolution" immediately.
2. Next, see how many issues have that resolution.  They're all going to need to be pushed through a transition that says "clear the resolution" on a post-function (or use the "fix resolution" canned script in the script runner)
3. Now go through ALL of your screens - make sure the resolution field is only in transition screens where people are closing an issue.  It must never go on edit or create screens.
4. Once you've done that, delete the "do not use this resolution" value from the list

[Nicolas Bourdages]

I sense the frustration from having to answer that same question over and over. It seems that every single JIRA admin has had that issue at some point. There are no good reasons to set a resolution anywhere but in a transition. I wonder why Atlassian doesn't just restrict the Resolution field and make it special like status, in the sense that it's changed through a transition and not an edition.

[Nic Brough -Adaptavist-]

I'd have gone one further and dumped resolution as the "how do we know it's done with" question.  If you care to search (although it's really boring and repetetive, so I wouldn't), you'll find my whinging on the subject going back at least 8 years

[Kristin Fast]

Thanks for the posts on this, it did help me figure out the reason for the strike-through's on my project.   

So to clarify, if you have ANYTHING in the transition post function at any status, including "Unresolved”, it looks at the fact that SOMETHING is the field, and considers it resolved and strikes through the issue ID.  

I noticed this specifically on the ALL status transition post functions that I have to create a post function for Resolution to be “None”, even though it still shows up on the issue and in search queries as "Unresolved".  

The trick here is that one is real, and the other is false - and it IS sneaky, since you can't tell visually if it's actually EMPTY or UNRESOLVED - because they both say “Unresolved”.  I know that Atlassian says this "isn't a bug" and it's "tricky" but this feels like a bug to me.  The work-around is to do a query to find these issues, change the status, change it back, and Wa-La, it removes the strike through. 

query:

resolution != EMPTY and status not in (Closed, Complete, Cancelled, Done)

[Nic Brough -Adaptavist-]

>actually EMPTY or UNRESOLVED - because they both say “Unresolved”

That's the reason we all scream "never add a resolution of unresolved".

[Jay Amin]

Kristin Fast explained it nicely for new Admins. It helped me get rid off strik-throughs for issues that were moved back from RESOLVED to a status back in workflow. We had few such issues that were RESOLVED mistakenly. When we moved them back, it retained the strike-through's even though I was setting the Resolution to "Unknown" via a post function. Based on Kristin's comments, I updated that post function to "clear" the Resolution field and it fixed it.

[Rodney]

I don't understand why this is OUR FAULT as WE BROKE something. It is now Aug 2019 and I created NEW stories with NEW Sub-tasks and they all started with the resolution "unresolved" which seems find as its an unresolved and open item so why is this still breaking Jira if we the users didn't set it this way this is the default out of the box setting for me. 

Seems like this is an Atlassian BUG that should have been fixed years ago.

[Nic Brough -Adaptavist-]

It's not a bug, it's allowing flexibility, including the flexibility to get it wrong.

• Personally, if we want to stop people making the mistakes, I would have added
  a pattern match to the resolution field settings, one that used a translator and synonym lookup to check that an admin was not trying to add resolutions with names like "unresolved" or "open" to the list, but I can't imagine that being perfect.
• a function that blocks addition of the resolution field to any screen that is in a scheme
• a function to block people adding screens with resolution on it into a scheme

Although my preferred option is really, as given above.

These, of course, massively limit flexibility and people would be demanding work-arounds.

Please remove the resolution field from the create screen.  It is not there by default (and nor is an "unresolved" type resolution name), one of your admins added it.  It is very rare that you want to be creating issues that are already done with.

[Rodney]

Sorry @Nic Brough -Adaptavist- it is a bug if for years people keep making the same mistakes then its a bug in the system or a bug in the design, or a bug in the UI. But it is a bug if enough users say its a bug, its a bug, don't condescend your users and keep saying there stupid because they ALL keep making the same mistakes over and over for years and years. 

Somehow something you say ISN'T the default keeps being added to peoples projects and defaults to "Unresolved" when its there.  So the facts that this is occurring to so many people across so many companies seem to contradict your statement about was is the default. I can tell you when the resolution field is present it defaulted to unresolved.

So regardless about what you or I claim the default is, allowing a "Resolution" to be sone to an item that is not also marked DONE seems pretty odd. Also to me it is odd if something that is NOT DONE and is UNRESOLVED  they seem to be the same because if it's not done then it clearly is not resolved as well.  Also what does Unresolved mean for a STORY seems more like a bug status.

If you guys want to keep this "FEATURE" make it configurable so people can turn it off or don't allow it on STORIES as stories don't really have resolutions.

Also, there should never be a reason to strikethrough an item that is not marked as done. 

Also, I have done what you say and I have removed the resolution field and it does not show on our stories now and they are still showing as striked through. We are ignoring it but it is very stupid for our NOT DONE stories to have a strikethrough on them.

[Nic Brough -Adaptavist-]

I think you have misunderstood a few things here.

• A semantic point mostly, but it is categorically not a bug.  A bug is an unwanted behaviour that the designers and builders of a system did not intend.  Jira is behaving as intended here.  So it cannot be a bug.  People complaining about it does not make it a bug.
• If you'd read the conversation in full, you would have seen that I don't condescend or call people stupid, I'm first in line to point out it's confusing, and that it's a poor way to handle this.
• They're not my users.  I'm not an Atlassian, and if I was, and had anything to do with it, I'd have changed it a long time ago, as described earlier.
• You say:  "Somehow something you say ISN'T the default keeps being added to peoples projects and defaults to "Unresolved" when its there. So the facts that this is occurring to so many people across so many companies seem to contradict your statement about was is the default."  This only happens as a default after an inexperienced admin makes the mistake (by adding the resolution screen to the default create or edit screen(s)).  My statement was that is NOT a default off-the-shelf, your admins have to change the defaults for it to go wrong.

Removing the resolution from the screens is a start - it will stop further damage happening, but you also need to

Ensure resolution is set as you go into status you want to have as end points (closed, done, ended, cancelled, etc) and cleared if you move from an end point back to an active state.  If you do not do this, Jira will continue to misrepresent open and closed issues.

You currently have a load of damaged data, in that you have non-ended but resolved issues. The ones still struck out although open.  Ideally, these will need to have their resolution cleared somehow (unless you just ignore it until they reach their end states).  Once you've fixed your workflows as above, you can move them through transitions with "clear resolution" on it, or maybe reach for a scripting solution with an automatic and easier fix (I'd do that if I had more than a handful of broken ones)

[Rodney]

Okay I have had a formal phone call with Jira support on this and reported it formally as a bug. They are reviewing it and also have stated that BY DEFAULT it is set to unresolved and that this is correct and that unresolved resolution does not mean closed.

So they are looking into this as it shouldn't be strike through if it is unresolved. So your whole premise in this thread and others similar ones is wrong I have it from the horse's mouth you are wrong on what the default values are for the resolution field and if you don't like it the many many steps you have to go through to change it.

Also, you do not seem to understand what a bug really is. A bug is not "just" unwanted behavior that the designers and builds of the system did not intend.  That is a very old school view of a bug.

Here are just a few, of the many, types of common bugs. 

• Bug in the design
• Bug in the code not working as expected
• Bug in the User Experience
• Bug in the test cases 

Also, the more modern approach is to not contradict the customer calling something a bug. As you can call it anything you want internally and contradicting a customer having a problem will only make them more upset, and most likely it is a bug based on the POV which is fine.

If 100's of customers are doing it wrong for years then there is a problem aka a bug that needs to be addressed in some way so that this stops accruing because telling them they are doing it wrong doesn't fix the problem that continues to occur.

The way you respond to issues is typically condescending and implying we are stupid when you say we are doing it wrong. When we are just doing it the way presented or appears obvious because Atlassian is bad at user experience design and making sure things a clear and obvious.

Oh, I know very much you are not an Atlassian employee and brought this up to Atlassian and the issues with the community forums and how they are being used for reporting bugs and problems when they agree that is not their purpose and they want users to report them via support and not to the community forum. This forum is supposed to help users help users with common

[Nic Brough -Adaptavist-]

So, with respect, you're ignoring the accepted definition of bug. Something like "A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways"

Jira is not producing an incorrect or unexpected result and it's not behaving in an unintended way (according to the people who wrote it)

I've emphasised a couple of phrases there after nicking the definition from wikipedia.

Mine was similar to that, but I wanted to point out the subjectivity I see. You are seeing "bug" as "it doesn't do what I want/expect", but I see a bug as above "it's creating an incorrect or unexpected result", which is something that is defined by the people who designed and built it, NOT those who see it. Atlassian see no bug at all - it's doing what they built it to do.

Bugs are objective, not subjective. It's only a bug when everyone sees the same behaviour and can agree that it does not work. In this case, you think it's broken, Atlassian think there is no problem, and I think that while it is doing what Atlassian designed, the design is poor for several reasons. It's only a bug when everyone can agree that it's wrong.

Now, getting back to the problems you are seeing, I think I can now work out what you are seeing and why.

>They are reviewing it and also have stated that BY DEFAULT it is set to unresolved and that this is correct and that unresolved resolution does not mean closed.

While this is absolutely right, and something I have also stated in this conversation, it skims over something that I think you have not picked up from the earlier posts. (There's a lot here, so it is easy to miss)

>So they are looking into this as it shouldn't be strike through if it is unresolved. So your whole premise in this thread and others similar ones is wrong

Nope. Every single time, I've said exactly that. Resolved issues are struck out. Unresolved ones are not. My premise is correct, and directly confirmed by what Atlassian said to you. But, I think you're missing something very important that I will cover later.

To be totally honest I have questioned this in the past in the forums, much as you are, but at a time when I was getting started with Jira. None of my original questions in the forums have been carried over here, so there's no evidence of it. But since I was corrected and came to understand how it works, I have consistently said exactly that - Resolved issues are struck out. Unresolved ones are not.

The problem here is that people don't get what unresolved and resolved are (and my complaint, alongside yours, and as I have repeatedly said before, and you are ignoring, is that this is a bad way to do it. Because we should not have to think to understand this!)

So. The TLDR version:

• Unresolved = empty (null) resolution field in the database
• Resolved = any value in the resolution field in the database
• To try to be a bit more human friendly, Jira displays unresolved instead of <nothing> when putting the field in front of us.

So, I am pretty sure that if you log in as an admin and go to the list of resolutions in your Jira, you are going to find that an inexperienced admin has added a resolution with a name of "unresolved".  Which leads to issues being resolved while showing unresolved.

You need to remove that, as described above.

Please let us know if this does not turn out to be the case - if nothing else, I'd like to know that there's another way to break it!

[Chris]

I'm been struggling with this issue for 5 years and finally resolved it thanks to this thread!!

[JRodney Estrada]

.

[Nic Brough -Adaptavist-]

No, you have the same problem that has been described above.

An inexperienced admin has added "unresolved" to the list of resolutions and then made it worse by using "unresolved" in that post function you've shown us.

You need to do three things:

Edit that post-function (and any others like it), so that they "Clear the resolution field".  If you hit edit on the left, you'll see it offers a select list of all available resolutions, with the current one selected, scroll up right to the top of the list and select <none> instead.

Go to your list of resolutions and rename "unresolved" to "do not use this resolution" (or "broken resolution" or anything that tells people it's broken and they shouldn't be using it)

Search for "resolution = 'do not use this resolution' and status in (<all status you consider to be open>) - you'll want to think about getting them unresolved.

[Remi vaucher]

Get the same problem after having set a resolution field set to "unresolved" into the CSV import.

Ran again the import with the field set to <<!clear!>> solved the problem

[Henry Staples]

Is it possible to make it more flexible and to turn off the relationship between resolution and strikethrough formatting? It's just another silly field that somehow got marked as an important relationship.

[Nic Brough -Adaptavist-]

No.  It's hard-coded throughout.

In fact, just being able to turn it off would make things worse, as we'd all end up asking every user about that flag as well as all the current stuff we have to.

"Resolution" really should be thrown away as the "done" flag.  If I had any control over Atlassian's development of Jira, I would be looking at a couple of ways of doing it, neither of which are remotely based on resolution. 

I like the resolution field, I like that it is a way to say "briefly, we reckon this is done because...", but it's now the wrong place to look at.  I want a set of relative groups of "done" status, with one group defined as absolute.  It should be status that says "done", with resolution saying "why it's done"

[Henry Staples]

Yes, I agree, thanks.

[rebekah]

Interesting enough, there are tickets that have the same resolution state (unresolved) that do NOT have the same strike through. 

Agile Board.jpg1346 Ticket_WITHOUT a strike through.jpg1345 Ticket_with a strike through.jpg

[Nicolas Bourdages]

Like Nic says, you have a resolution that's literally named "Unresolved", while JIRA displays "Unresolved" where there is no resolution. It's sneaky.

[Nic Brough -Adaptavist-]

Those issues are properly unresolved, rather than unresolved.

That is, the ones with a strikethrough are resolved, because you've put something in the resolution field.  Doesn't matter that the word you have used is "unresolved", the field is filled, therefore the issue is resolved.

The unresolved ones without a strikethrough are unresolved because the field is empty.  JIRA is displaying unresolved because the field is empty and it wants to show you something other than a blank space.

[Nicolas Bourdages]

This is a very common issue. "Unresolved" counts as a resolution. Basically, you need to make sure that the Resolution field is only set in a transition screen to a Resolved status (or equivalent).

https://answers.atlassian.com/questions/95752

[Rodney]

Why ?? This is the default resolution for new issues/sub-tasks why is this a resolution for something that is still set as TODO. Seems like Atlassian is to blame here and should fix this as its still an issue in 2019.

[Nic Brough -Adaptavist-]

Or we could just use the software as it is intended to be used, and not set the resolution field until the issue is resolved.

[senthilkumarn]

Hi 

I don't set the Resolution field itshelf, But when i create a ticket. I see the field is present.

even when I close the ticket it says Unresolved.

How to fix it.

[Nic Brough -Adaptavist-]

This suggests you have had an inexperienced admin add "unresolved" as a resolution in the list of options, AND placed it on the "create issue" screen.

Remove the field from the screen immediately, then rename the "unresolved" resolution option to something like "broken resolution - do not use".

You'll then need to look at all the issues with that incorrect resolution set to see how best to fix them.

[senthilkumarn]

Hi Nic,

First i would like to thank you for replying me

No i dont see that field in Create Issue screen or any screens

First i had an issue, when i move a ticket from DONE to INprogress, i had the strike in the ticket which is moved to IN-PROGRESS

So i have added an Post function in the workflow for the transition, which moves from DONE to IN-PROGRESS and it got fixed

Now when i move a ticket from IN-PROGRESS to DONE, i am not getting the strike on the ticket.

Can you help me on this please.

[Nic Brough -Adaptavist-]

>But when i create a ticket. I see the field is present.

I am sorry, I misunderstood that to mean it was present on screen when creating the issue.

The strike through appears when there is any value set in the resolution field.  So, when you were moving from done to in-progress, the field is either on the transition screen, or being set by a post-function.  As you've now added a post function to clear it, I'd guess you have the resolution on-screen (otherwise I think you would have seen the existing "set resolution" post function when you went to add your "clear resolution" post-function)

You need to do the opposite in the in-progress to done transition - either put resolution on a screen for the transition or set it in a post-function.