Removing Strike Through

[Sarah Shonnard]

Is there an easy way to remove the "Strike Through" font modificaiton to Issue IDs completely within Jira?

We don't really need it for our workflow and it seems buggy (like lots of issues not in a resolved state show up with strike through font)

I'd like to just disable it completely.

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

issues are rendered with strikethrough when there is a resolution set. It is not buggy - you will not see it if some specific transitions doesn't set resolution.

If you don't want it, make sure you don't set the resolution field at all. Check your work flow post functions and remove if there are any.

[Nic Brough -Adaptavist-]

There is no fault, but there's two glaring ways this can happen:

1. Indexing problems. Could you try re-indexing and see if that makes it consistent?

2. You may have had an inexperienced admin add a resolution of "unresolved", which neatly messes the whole thing up - check the list of resolutions, and remove it if they have, then you'll find the strikeout behaves correctly.

If you absolutely need to remove the display, and hence downgrade the information being given to users, you'll need to modify the CSS in a couple of places in the core code to get rid of it.

[Nic Brough -Adaptavist-]

Also remove it from transition screens, or your users will set it inadvertently.

[Nic Brough -Adaptavist-]

Oops, sorry, missed the "xml" part of your comment. An export won't help you that much - there is a simple "set field to ..." function built into Jira you can search for, and when that is configured to change the resolution, yes, you'll be able to spot it. But then you also need to spot transition screens with resolution on them.

[Sarah Shonnard]

We use the resolution field, so I can't take it out of the equation. It seems to set the font for resolutions of "Unresolved" even if the status for the issue has never been set to "Resolved".

Regardless of if we can agree on if there's a defect here or not, I need a way to turn it off completely.

If I export my post functions to XML is there an easy way to search for the function which sets the font to strikethrough?

[Sarah Shonnard]

I'd be happy to add some javascript to remove the CSS class. Do you have any sample code which does this?

[Jobin Kuruvilla [Adaptavist]]

You can find out from XML everything that sets resolutions automatically. But as Nic pointed out, it may be set by users on resolve screen as well.

The only way to turn it off would be add some javascript that removes the CSS class which causes this formatting.

[Sarah Shonnard]

I am the inexperienced admin for our system. I did add a resolution of "unresolved" (actually I think it was there by default) but we use it.

While you may feel it's less info, in our case I don't need it. We do everything within Green Hopper, so Resolved and Closed items eventually fall of the backlog.

[Nic Brough -Adaptavist-]

Ah, yes, it's a trap many fall into, and it's not brilliantly clear in the docs either.

Jira sees the resolution field as <null> or <something from a list of strings>. It displays <null> as "unresolved". But if you add "unresolved" as an option, it sees them as resolved, because the field now has something in it.

I'd remove the value from the list and set all the issues that had it to the "unresolved meaning null", then at least it will be consistent.

Even if you downgrade the display by changing the CSS so that it matters less, you should still do that, because the Jira reporting that some of your users may be using also use the resolution (it's not a "feeling" that it's less information - it's a simple stark fact that a strikeout is immediately more clearly "done", even if your users only use GH - everywhere I've been people have liked the strikeout, although it's sometimes asked if we can change it to a colour or font - they need something to show "done")

[Sarah Shonnard]

Nic, is there any chance we could do a brief live debug session on this? I'd like to show you exactly what I'm seeing, and get your input on what adjustments to make. I follow what you've said so far, but I'm not sure how to proceed given what I see in our system. There are items with the resolution set to "Unresolved" which exhibit different behaviors, so I'm confused. e-mail me directly if you can spare a few minutes to hook up live.

[Sarah Shonnard]

Never mind ... I figured it out ...

[Ben Reimer]

Tony, can you share how you were able to do this? I would like to get rid of the strike through on items that are moved to resolved without being closed. I am unable to edit the workflow based on how our company has jira setup at the corporate level. Any help you can give would be appreciated.

[Sarah Shonnard]

It's not a perfect solution. Strike through comes from "Resolution" being set. I simply edited the workflow so that every time you transtion from one state to another (other than to Resolved or Closed) it clears the Resolution field. I have a filter on a dashboard that shows me any Non-Resolved/Closed issues with the resolution set. When I see one I simply transtion the issue to the same state it's already in thereby clearing the Resolution field. Not optimal because it's a very manual process, but it's the best I could come up with. Also, in your case it doesn't sound like this will work for you since you don't have the ability to edit the workflow.

Sorry my solution isn't more helpful.

[MattS]

Ben, you need to able to edit workflows to do this, so you need JIRA admin access. If a workflow never sets the Resolution, and the standard Resolution field does not appear on any screens, including transition screens, then no value should ever be set in the Resolution field and no strike through will occur.

Make sure you don't have a custom Resolution named Unresolved, since that is how JIRA displays issues with no resolution at all set.

To clear a resolution that has already been set, do as Tony did and add transitions back to the same status with a Set Field post function to clear the resolution. It's a hack but that's how people do it.

[Sougandhi k]

I tried moving a bug from backlog to existing Sprint. The bugs are getting Stroked off and the resolution is a mandatory field to be selected. Only the Jira admin will have the rights to edit the workflow for the bug cycle. Is there any way this could be resolved without modifying the workflow.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Technically, the resolution field is not "mandatory" because it can, and should, be left empty until the issue is resolved.

What is actually happening is that your people cannot select "empty" ("none") from the resolution list when the issue is in a create, edit, or transition screen.

You need your administrators to fix your workflow and field usage.  They need to

• Remove resolution from almost all screens your project uses.  It should only be used on the transition screens that take an issue into an end status (closed, done, ended, complete, cancelled)
• Add "update field: resolution, set it to None", or use "clear field: resolution" post-functions to any transition that re-opens an issue

There's no way for a non-admin to fix these broken workflows I'm afraid, you need to get your admins to fix it.

[Richard Ranft]

"Not buggy?"  Really?

Here, compare these two images. The first one is the raw text, note the dashes for command line flags:

what_I_want.png

Now, look at what it does when I accept this:
what_I_get.png

Does that look like desirable behavior? 

I don't believe that is how it should work, and yet it is still that way two and a half years later.

[Nic Brough -Adaptavist-]

Er, 2.5 years old, but also behaving exactly as expected.  Nope, not buggy.