Issue Links are striked through but resolution is not set

[Christof Hurst]

Hi, 

normally issues are striked through as soon as resolution is set.

Actually it seems that this strikethrough only references to status category done.

As we have a green status for "Active" we don't want to display issues with strikethrough. Perhaps only in free version in the cloud??

Any idea how to prevent?

Please do not tell me the issue has a resolution set with name "unresolved" because it has NOT!

BR 

Christof

[Christof Hurst · Accepted solution]

It's also completely reproducable with a new Open-Done workflow with no postfunctions to set the resolution. Just link to issues, move one to a status with status category Done and the issue will be displayed strikthrough.

[Christof Hurst]

It's officially a bug: 

• JRACLOUD-76915:Strikethrough appears on the Parent Issues child list despite that the Status' Transition sets the Resolution to be Cleared 
• JRACLOUD-76935:Linked issues are strikethrough when it is transitioned to the Done status category without resolution 

[Nic Brough -Adaptavist-]

Actually, the issue is resolved.

Your screenshot shows the green status with "unresolved" next to it as the resolution.  So someone has resolved the issue by selecting a resolution.

If the issue was unresolved, then there would not be anything showing to the right of the status.

An inexperienced administrator has added a resolution called "unresolved" to your system, and probably put it on some create or edit screens.

To fix this, you should

• Go to the list of resolutions and rename "unresolved" to "aargh no" or something else that makes it clear to your users that they should not be using it.
• Go through every screen you have and remove the resolution field from them, unless they are a screen only used for transitioning an issue to a closed status
• Unresolve every issue that is in an open status with an "aargh no" resolution, by pushing them through a transition that has a "clear resolution" post-function, or by using a script or automation to empty the field out.
• Delete the "aargh no" resolution from the list

[Christof Hurst]

No, the issue is NOT resolved!

Resolution IS EMPTY!

There is no resolution "unresolved" in the system. I am very experienced and I know what i do.

[Christof Hurst]

[Nic Brough -Adaptavist-]

In a company managed project, the resolution does not show "unresolved" when the resolution is empty.  There is nothing shown at all.

The issue in your screen shot has a resolution set.

[Christof Hurst]

Again, the resolution is not set! Look at the issue navigator results. 

[Nic Brough -Adaptavist-]

I'm sorry I have to disagree with you, but almost all the evidence is that this issue is resolved.  You are getting strikeouts when displaying it, and the issue view shows a resolution set on it.

The issue navigator result suggests that there is something wrong with the index for this issue.

The issue view is done directly off the database, not the index, so it's the think you should be looking at as the "source of truth", not the issue navigator.

[Christof Hurst]

I have only four resolutions and none is named „unresolved“. A reindex can‘t be triggered. this wrong behavior is since days. 
And I am pretty that never ever this issue had set any resolution. 

[Christof Hurst]

But I will give it a try and set and unset a resolution 

[Nic Brough -Adaptavist-]

This is definitely one that needs more investigations and testing.

You can make Jira re-index a single issue - just make a change to the issue (not comments or attachments though).  If you edit an issue and change any field, the whole entry in the index gets refreshed.  I usually just edit a text field, adding or removing something that won't change the meaning of the content.  (Or correcting my grammar if I created the issue when I was tired ;-) )

On top of the good tests you've suggested, I would want to see the list of resolutions defined in Admin -> Issues -> Resolutions, and compare it to what you get in the menu when you click the down-arrow next to the resolution in your screenshot.  You say you have four resolutions, so I would expect the drop-down to have five entries.

[Christof Hurst]

As expected, nothing changed.

The issue is still without resolution. 

I also explicitly set resolution and cleared it but nothing changed. Either it's a bug or actually the status category done is displayed with strikethrough.

[Christof Hurst]

It can't be the index because when switch to a not green status, the strikethrough is gone. As soon as switching again to green Aktiv status, is strikethrough. So it MUST be status category.

[Christof Hurst]

[Nic Brough -Adaptavist-]

It's nothing to do with the status category.  The code doesn't even look at the status when it's looking to see if an issue is resolved or not.

Your screenshot clearly shows a resolution is set on the issue, and that's why you are seeing it struck out.

Could you do us another screenshot, same as the Aktiv / unresolved / rechung one you did before, but when the issue is in another status and there is no strikeout?

[Christof Hurst]

The screenshot shoes clearly that no resolution is set. Because there is no green hook, the history shows change to „none“, etc.

in a not green status the resolution field is hidden beside the status. 

 I recommend to reproduce the behavior in your instance. It‘s simply reproducible. New workflow with open and close, two linked issues, at least one is in close status. 

[Nic Brough -Adaptavist-]

Sorry, but no.  The screenshot that has Aktiv / Unresolved / Rechung is 100% clear - there is a resolution set on that issue.

I can indeed reproduce this on my Cloud systems, in both team-managed and company-managed projects.

But to do it, I have to add a resolution named "Unresolved" and set it on the issue.  The status, the status category, all the other things that might feed into "done" have no effect.  I have to set a resolution to get the display of it and the strikeout.

[Christof Hurst]

Ok, I don‘t think you really tested it. It’s completely reproduceable without setting resolution. Let‘s stop discussing if you don‘t respect my findings. 
btw. The resolution is only set when a green hook is before the text. 

[Nic Brough -Adaptavist-]

I absolutely did test it, every combination of possibilities you have shown us.

The only way I could get the "unresolved" to appear on the issue view (and hence do the strikethrough) is to create a resolution called "unresolved" and set it on the issue.

You should equally respect my findings on this, because that's what I am getting - it is working as designed and expected, like most of everyone elses.  And your system does not seem to be.

Next thing to look at is your workflows, automations, listeners and scripts.  Do you have any post-functions on the transitions into the status that should not be resolved?  Could there be automations, listeners or scripts that are acting when that transition happens?

[Christof Hurst]

I can it reproduce in another instance. Simple new workflow with OPEN and CLOSE, no automations, no postfunctions, no listeners. Completely new everything. Nothing but the two statuses. Same behaviour.

Resolution is not set (visible). Not in issue, not in issue navigator, not in groovy REST call result. It is not set. Definitely.

Both System has no resolution "Unresolved" nor "None". The issue has no resolution.

[Nic Brough -Adaptavist-]

Hmm.  I think we're getting closer to finding it.

How exactly are you replicating it?   What modifications to workflow and screens are you making after creating a project off-the-shelf?  Here's a run through of my testing to see what you might be doing differently (shared schemes is my guess)

My test steps were:

• Create New project
• Scrum
• Company managed
• Don't share settings
• Create a few stories or tasks (stay away from the sub-task and epic edge cases, stick to the simple one)
• Click on issues to get to the issue list, and see this on one of them.
• 
• and then clicking through to one of them
• Note the lack of anything to the right of the status - the issue is unresolved because there is nothing there.
• Close issue, and we see resolution set automatically (the default workflow does it)

• 
• However, also note that the resolution there has no drop-down option (hovering over it gives a tool-tip saying that the resolution cannot be edited)
• So next, I edit the project settings and add the resolution to the issue edit screen
• The drop-down now lets me change the resolution to any value I have in the global resolution list - the drop-down arrow has appeared.
  
• If I re-open the issue, the resolution value disappears, back to the second screenshot I have here.
• I can't change the resolution to "unresolved" because it is not on the list of resolutions to change it to.
• But I can make it appear -  (temporarily) adding "unresolved" to the list of resolutions, then I get exactly what you are seeing and I can set the issue to "unresolved" with an edit (and then the strikeout and all the other behaviours I expect to see from a resolved issue happens)
  
  
  This series of tests has made me think of something else though - to get what you are seeing (with the drop-down to let you edit the resolution), you must have put the resolution on the issue edit screen. That's something you should not do, because it means any edit to the issue then sets the resolution, and hence resolves the issue.
  Which leads on to the next question - if you edit a resolution by using the drop-down, changing it to any of your done / duplicate / designed / known options,, then what happens when you edit it again?  Are you offered "unresolved"?  If you are, and you select it, what does the issue history say you changed in both edits?

[Christof Hurst]

Keep it simple. I just made a new workflow with two statuses, Open and Done. One transition to Done and one back to open. No postfunctions, automations or any other adjustments. No automations.

Then two tasks in a project, linked together. One closed -> will be shown stroke through in the other. No resolution set. Check in Issue Navigator and in groovy REST call.

----

Forget about the dropdown. The wording "Unresolved" for null value confuses. A set resolution is marked with a green checkmark. So my screenshot showed a not resolved issue. It was just for testing. When setting to "Known error" that was marked green. Reset to Unresolved is not possible via the dropdown. Must be done via Postfunction. As shown in the screenshot, Resolution changed from "None" to "Known error" and back to "None". So resolution is defintely not set and empty,

[Christof Hurst]

Please make a test with

• Issue in Done status
• but no Resolution
• Resolution field available on the edit and view Screen

You will see a dropdown right beside the green status with 'value' Unresolved but no green Checkmark. That means, that the field has no value but you can choose one.

[Nic Brough -Adaptavist-]

Nope, that is not what happens, but it is close.

I get "done" shown next to the status, not "unresolved".  This is because the default for the resolution in this system is "done". 

If I change the default it to the (temporarily added) "unresolved" resolution, then I get "unresolved" there instead.

Both of those are exactly what I expect to happen given the configs.

So, the next test I'd want to try on your system is to go to Admin -> Issues -> Resolutions, and change the default from "unresolved" to "known error" (I picked that as the least likely to look wrong to your people during that test), and try creating/editing an issue again.  What does a new/edited issue look like after you do that?

[Christof Hurst]

You also get "Unresolved" shown there if you do NOT add the wrong resolution to the resolutions. If you have an issue with NO resolution in a green status and resolution field present on view/edit. As I described in the test scenario.

• I have no default resolution 
• I have no resolution "Unresolved"

One last time: the issue has no resolution. Confimed via Groovy/REST, confirmed via Issue Navigators, confirmed via history. Additionally confirmed via removing the (non existing) resolution via postfunction. Defintely no resolution.

So it must be a bug. Or a feature to show issues with status category done stroke through. No other possibilities.

I don't want to discuss this anymore. Either there is a reason, why an issue is stroke through without having a resolution or it's a bug.

[Nic Brough -Adaptavist-]

I understand, I will shut up and leave you alone, but I would like to close this conversation on a friendlier note.

I just wanted to end by saying that I don't want you to misunderstand why I've talked so much about it.  I have not been trying to say "you're wrong", my tests, questions and "are you sure" type stuff have mostly been about my curiosity, because 

• I would like to get it fixed for you (and anyone else who may be seeing it)
• I am horribly curious about how you're getting this problem, when we can't
• I love a good puzzle or challenge, and this certainly has been one

So I apologise if I've seemed over-persistent or nagging.  Even though we haven't got to the root of the problem and fixed it, I want to say you've been one of the best questioners I've engaged with recently - you've thought it all through, provided clear, informative and helpful answers to every one of my dumb questions, and anticipated and performed most of the stuff we usually put into "can you try this next" responses.

But I understand that it is tiring and you've had enough.  I hope I've not put you off asking your next Atlassian question here, by not being able to answer this one.

One last little thing though.  Would you like Atlassian to take a look for you as well?  I think it's something that an interactive session with another Atlassian admin might help with, and it's certainly something they'd want fixed.  I can ask them to get in touch, no matter what the level of your licence.

[Christof Hurst]

I really appreciate your help Nic.

But here it was really frustrating. I gave a clear scenario, told what's configured in my system and nobody believed me. You also "reproduced" a completely other scenario.

It's very hard if I tell time over time that the resolution is not set. Confirmed in many ways. But again and again the resolution was mentioned as solution. In this way nobody can find a solution. I am very experienced and know what I'm doing. If I ask a precise question and everyone tells the same that I already excluded, then nobody can find a solution.

The small steps I told are reproducable in another instance for me. For this I could already open a support ticket with atlassian but have no answer.

Thanks Nic for your words.

[Trudy Claspill]

@Christof Hurst 

I was able to recreate what you are seeing. I am also using a Free subscription.

First, in my Board Settings > Columns, for the Statuses in the Done column I unchecked the box for setting the Resolution field.

In my case, I also did not have a screen attached to the Transition to Done that would let the user set the Resolution field.

When I then transitioned an issue to Done, the Resolution field remained empty.

Notice the Resolution value shown in the search results is italicized. When the Resolution field has an actual value in it, the text is not italicized.

If I looked at that same issue under the Linked Issues list of another issue, then I saw the issue key struck through.

At this point I did not see Unresolved next to the issue's status...

...HOWEVER I did manage to change that. By going to the Screen Scheme and adding the Resolution field to the View/Edit screen I was able to get "Unresolved" to display next to the Status, just like you see.

[Christof Hurst]

Thanks Trudy for reproducing the issue. Now we have three confirmed cases and it seems that just the status category is causing the strikethrough.

I will show the atlassian support the thread.

You are the first one to believe me and my findings. Thanks.

[Nic Brough -Adaptavist-]

This is getting really weird.

I followed exactly what Trudy did and I still do not get an "unresolved" message next to the status.  I tried it on both a free and an enterprise install.

But the solution remains the same - don't put the resolution on the edit screen.  It should not be there.

[Trudy Claspill]

While I agree that having the Resolution field on the View/Edit screen is a bad practice, that is not actually a solution to the problem from the original poster.

;-)

The original question was how to prevent a strike through on the issue when it is in a status that is part of the Done status category but has an empty Resolution field.

[Nic Brough -Adaptavist-]

Yes, it's preventative, but the problem is that a resolution is being set because the field is on the screen.  

Removing the field will stop it happening again, but the resolution set on existing issues needs to be removed too, and the solution to that is clearing the resolution by transitioning the issues to clear it out.

[Christof Hurst]

No, that's still NOT the solution because the resolution is NOT set. Despite if the field is on the view or edit screen. I agree that this is not common practice but it is not the reason for the problem. 

Trudy (and I) put just a field on a screen to proof the field is unset. And it is. Putting a field on a screen does not change the values in an issue.

But the resolution is not set and was not set. The problem still is, that the issue is stroke through WITHOUT a resolution is set.

You did not get the "Unresolved" string because your resolution is set. Make an issue without  a resolution in a green status. Then you will get the "Unresolved" string IF you put the resolution field on view and edit screen.

[Trudy Claspill]

@Christof Hurst 

I had a clarifying question I wanted to ask.

You posted this in the Service Management community. What is the project type that you are working with - Software, Service, or Business/Work Management? And are you working with a Team Managed or Company Managed project?

To be clear, when I was recreating this, I used a Company Managed Software project. I'm not sure if the same would be seen in Team Managed or in Service or Business projects.

[Christof Hurst]

I tested in different projects. With company managed projects. Last test was in SD project, former test was in business project. 

[Christof Hurst]

I would really appreciate if you all vote on the bug tickets

[Fabio Racobaldo _Herzum_]

Hi @Christof Hurst ,

That behaviour is not specific for free or paid plan. In the past I remember that linked issues were striked or not based on resolution (https://community.atlassian.com/t5/Jira-questions/Why-is-there-a-strikethrough-on-a-To-Do-ticket-with-unresolved/qaq-p/1847028) but, righ now, it seems based on the category status. 

I searched something about that within Atlassian backlog but there are not bugs for that. 

I really don't know if it is a bug or a new approach. 

Fabio

[Christof Hurst]

I hope it's a bug. But as I have a free plan I can't raise a ticket at the support.

[Christof Hurst]

It's a bug. can you please vote on it?

[Alex Koxaras -Relational-]

Hi @Christof Hurst 

I screenshot of what you are facing would help a lot. In addition can you please say if you are on TMP or CMP projects?

From what I can assume is that:

• These issues could be reopened and transitioned to a status, without clearing the resolution
• Someone added a PF to a specific transition which set the resolution

[Christof Hurst]

What should a screenshot show? The issue is strike through and the resolution is not set...

Again, the resolution is NOT set!

All projects company managed.

[Andy Heinzer]

Hi @Christof Hurst 

It appears that you are not using Jira Software in this site, but rather the features of Jira Work Management.  If that is correct, then you should be aware of this known issue JWMCLOUD-210

On Business projects (which have their own boards), the issues will be set to Done, but not have a resolution value set on them when this happens.  It is a known issue that seems to be affecting you here.  I'm afraid the other answers on this thread could apply, if you were using a company managed Jira Software project, as the boards and workflows in those project types rely upon different code there.

But there is a noted work-around on that bug ticket whereby you can setup an automation rule in order to automatically set the resolution field value when the issue reaches that specific Done transition.

I hope this helps.

Andy

[Joseph Chung Yin]

@Christof Hurst -

As suggested by other community leaders, In Jira/JSM, issue strikethrough marking is activated when issue's resolution field is set.  

I agreed with @Nic Brough -Adaptavist- comment that in the CLOUD env, if the issue's resolution is not set, then there will be nothing displayed (next to the status) example -

From your image captured in your reply to @Alex Koxaras -Relational- , the fact that a resolution is presented, it means that CRM-3 has a resolution value.  You should look into "Settings" >> Issues >> under the Issue Attributes section >> Resolutions configuration to ensure that there are no option named "Unresolved".  If it is found, then you should either delete it or rename it to something else.

I would also recommend you to review the WF against the transition to "ACTIVE" (regardless of it's status category association) to ensure there is no post-function call where the resolution is set.  Lastly, examine your WF on all the transitions to check where the resolution value is set and unset as needed.

It is my understanding that Jira/JSM uses "Unresolved" as an internal representation of NULL value for the Resolution field.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Christof Hurst]

You are also wrong. There is no and there was never a resolution named "unresolved". I'm not stupid. I know what I'm doing. Also the issue had never a resolution before

The resolution field is presented because I added it on the Screen to test. As soon as I select a resolution, it is still displayed but with a green hook in front. This means, a resolution is set. My screenshot just shows, that NO resolution is set. So it's unresolved and you are right as this means NULL (or None).

[Joseph Chung Yin]

@Christof Hurst -

Please don't get us wrong, all community leaders (@Nic Brough -Adaptavist- / @Alex Koxaras -Relational- / @Fabio Racobaldo _Herzum_ and myself) are just trying to assist you with our knowledges and experiences with Jira/JSM.  I know you know your stuff and not to saying that you are not.

At this time, I would recommend you to report this oddity to Atlassian Support for their insights on this matters.

Best, Joseph