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.
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.
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.
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.
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?
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.
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.
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")
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.
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.
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.
"Not buggy?" Really?
Here, compare these two images. The first one is the raw text, note the dashes for command line flags:
Now, look at what it does when I accept this:
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.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs