New issues are strike through

[Lior Israeli]

Hello,

How come new issues that are just opened, appears on the activity stream as strike-through?

[Nic Brough -Adaptavist- · Accepted solution]

You've set something up that sets them as "resolved" as they are created.

Or your users are *really* quick at resolving them ;-)

[Lior Israeli]

thank you for the prompt answer but every issue that is opened is marked like this, no resolve or other action taken.

:(

[Nic Brough -Adaptavist-]

Ok, pick one of the newly created issues and look at the issue in Jira - what does the "resolution" field say?

Also, can you do a search and view it in the issue navigator? Make sure the "resolution" field is in the result as a column - what does that say (I'm fishing for the colour of whatever it says as well as the text here...)

[Lior Israeli]

It is all unresolved - I've attached screen shots

[Lior Israeli]

I'm using OnDemand.

On the activity stream the ID is strikethrough while the title is regular text (both blue - link)

On the issue screen the resolution is 'Unresolved' blck normal font

On the issue navigator the tresolution is 'Unresolved' blck Italic font

Link to screen shots: https://dl.dropbox.com/u/92679/JIRA.doc

[Nic Brough -Adaptavist-]

I think your karma mght be too low to allow screenshots. Can you tell us what colour the issue's resolution is in the issue navigator?

Also, what version of Jira are you on, and do the strike-throughs appear when viewing the issues in their main view screen?

[Nic Brough -Adaptavist-]

Hmm. That's looking right, barring the activity stream. Could you check your list of resolutions under Admin -> Resolution. Make sure that there's definitely NOT one on the list for "unresolved"?

If there is not, then I'd raise this with Atlassian OnDemand support, as it looks wrong to me.

[Lior Israeli]

I did not fully undesrtand what should (or should not) be on the list.

The current list is: Fixed (Default), Won't Fix, Duplicate, Incomplete, Cannot Reproduce

What does it mean to you?

How do I raise an issue with OnDemand Support?

Thank you for all your help :)

[Nic Brough -Adaptavist-]

The list of resoltions is more of a sanity check than anything. Some people don't grasp that "unresolved" is a spectacularly bad option to add to the list, and do it without engaging their brain and then wonder why it looks odd. I just wanted to rule that out as a possible problem. Your screenshots pretty much said it already but there's a good chance you'll be asked.

For a support call, raise it in https://support.atlassian.com/browse/JST

[Rodney]

Wow, this goes back further than I thought all the way back to 2012. This is crazy. This is still defaulting to a resolution "unresolved" in 2019.  Atlassian really needs to fix this problem so it cannot possibly be set to anything other than none when you create a new issue or sub-task.

They have had at least 7 years with this issue ongoing and constantly people bringing it up.

I see this time and time again, for lots of things and its really annoying. I am not sure why our company or any company pays for Jira when it never seems to work without any issues. There is always some problem that is hit. 

[Lior Israeli]

The strike-through is shown because the filed 'resolution' was on the default issue screen and is a required field.

Once removed from the screen problem solved :)

[Dipika dhingra]

How to remove a required field.

[Nic Brough -Adaptavist-]

Make it optional in the field config and, if it is the resolution field, remove it from the Create and Edit screens.

[Nic Brough -Adaptavist-]

Yes, the "specific value" is "anything", as opposed to "nothing" This field is used by Greenhopper/Agile, but it is part of the core of Jira.

Whether you think you need it, or even use it, you need to be aware of it. The whole of Jira works off a simple idea - if the resolution is set to anything on the resolution list, then the issue is complete, and struck through. If the resolution is NOT set (nothing in the field in the database), then the issue is "unresolved" and shown clean.

It does sound like another admin has been tinkering and has modified your system to set it to something. You'll need to establish where it's being set and stop it.

For what it's worth, it's well worth a look at the Jira default workflow to see how it's handled in there - you'll see it being set on "resolve" and "close" transitions, and cleared on the way out of thm!

[Sanjay Kumar]

You saved a lot of time of mine. Thanks !

Solution that works for me:

Actually I created my workflow and set resolution on various transition. I just unset all resolution feild by selecting option "None" which says Resolution will be cleared.

[Lisa Rahder]

We removed the Resolution field from the default screen. Problem solved.

[Lisa Rahder]

So would the best transistion-state to associate the post-function with, be the first one (since I never want this field to have a value)?

[Lisa Rahder]

(We are running 6.0, but the post-function interface described in the documetation for this version does not match what we are seeing...)

[Lisa Rahder]

Thanks, Nic.

The funny thing is, we literally never use this field: it was not even dispayed in issues since we installed the tool until I read your responses in this thread and forced display in those issues where the number was struck through. So our users have not entered anything into this field, and will not be doing so.

We never use JIRA's defect tracking functionality or fields associated with it.

I will see what I can learn about applying post-functions... Thanks.

[Nic Brough -Adaptavist-]

You should not need a post function. Just remove resolution from the screen - that's what the problem is - the users are setting it simply by going through a screen with it on.

You do need to think about this field - even if you don't have it on any screens, it's worth blanking and setting in your workflow so you can identify "closed" issues.

[Lisa Rahder]

"None", null, blank is not an option for this field.

[Nic Brough -Adaptavist-]

Ah, hang on, I have not been clear. I apologise. This is a quirk in Jira I keep forgetting about.

None very much is an option for this field. However, the field assumes that if you put it on-screen, you are wanting to set it, so it does not offer you "none".

You need to make sure the field only appears on transitions that enter status which you want to consider "closed". You can set it in post-functions, and that includes "clearing" the value. If you put it on other screens like "create" or "edit", then your users will set it inappropriately.

[Lisa Rahder]

OK, so last question (...promise!)

Do you know which of these Resoltuon values will not cause a strikethrough...?

Thanks again!

[Nic Brough -Adaptavist-]

I already answered that. NONE of them. The field needs to be empty.

[Lisa Rahder]

Thanks for the info, Nic.

We do not use GH for defect tracking, and this field was not displayed (and we have never gotten these strikethroughs before). I added it, and saw that the default value was "Fixed", as you said (so must be a system, default...?). Anyway, I changed the Resolution field value to a differnent one, saved, refreshed, and the issue is still struck through.

Is there a specific value the Resolution fields needs to avoid the strike through? (Also, does it sound to you like an admin somewhere modified the default value of this field, which is why all of a sudden we a getting struck-through values on new Strory issues added to the backlog, when we never did before?)

Thanks again.

[Lisa Rahder]

... more clues.

When I initially added these 5 new issues they were "stories, no strike through. I then added a new issue type, retruined to teh board, and one of hte priginal stroies had a strike through - not the other 4. As I then changed the issue type from story to the new type, each would have a strike through on save...

[Lisa Rahder]

Initial status on workflow is "To Do"... not "Done" (no resolved as option on issue status)

[Nic Brough -Adaptavist-]

Status is NOT resolution. Look at the resolution field. The strike through is controlled by the resolution.

[Nic Brough -Adaptavist-]

It's much the same as above, you've set up the workflow to set a resolution as the issue is created.

Check that the "create" screen does NOT have a resolution field, and that there are no workflow post-functions that set the resolution.

[Lisa Rahder]

I am experiencing the same thing, new issues (stories, in my case) added to the backlog - not in a sprint, not under development yet - are struck through.

I am in a dev GH board, not Bug/defct tracking board.

Also see that if new Issue is story, and you change the issue type to a custom type, the number of the original story is struck through on save: again, brand new, no action taken on issue, defualt status...