Hello,
How come new issues that are just opened, appears on the activity stream as strike-through?
You've set something up that sets them as "resolved" as they are created.
Or your users are *really* quick at resolving them ;-)
thank you for the prompt answer but every issue that is opened is marked like this, no resolve or other action taken.
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...)
It is all unresolved - I've attached screen shots
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
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...
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.
Initial status on workflow is "To Do"... not "Done" (no resolved as option on issue status)
... 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...
Status is NOT resolution. Look at the resolution field. The strike through is controlled by the resolution.
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.
OK, so last question (...promise!)
Do you know which of these Resoltuon values will not cause a strikethrough...?
Thanks again!
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!
I already answered that. NONE of them. The field needs to be empty.
"None", null, blank is not an option for this field.
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.
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.
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)?
(We are running 6.0, but the post-function interface described in the documetation for this version does not match what we are seeing...)
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.
We removed the Resolution field from the default screen. Problem solved.
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.
How to remove a required field.
Make it optional in the field config and, if it is the resolution field, remove it from the Create and Edit screens.
It looks like you're new here. Sign in or register to get started.
