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?
Two things - remove the data that breaks JIRA, then repair the broken ones.
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.
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 :wink:
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.
resolution != EMPTY and status not in (Closed, Complete, Cancelled, Done)
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.
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.
It's not a bug, it's allowing flexibility, including the flexibility to get it wrong.
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.
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.
I think you have misunderstood a few things here.
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)
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.
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
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:
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!
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.
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.
>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.
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.
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"
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events