Removing Strike Through

Sarah Shonnard December 12, 2012

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.

2 answers

1 accepted

0 votes
Answer accepted
Jobin Kuruvilla [Adaptavist]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 12, 2012

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 12, 2012

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.

Like Aneesh Gupta likes this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 12, 2012

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 12, 2012

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 December 12, 2012

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 December 12, 2012

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]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 12, 2012

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 December 12, 2012

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 12, 2012

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 December 13, 2012

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 December 13, 2012

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

Ben Reimer March 3, 2014
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 March 3, 2014

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 3, 2014

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 November 9, 2023

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 9, 2023

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.

0 votes
Richard Ranft October 13, 2016

"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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 13, 2016

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

Suggest an answer

Log in or Sign up to answer