issue id strike through when issue is not resolved

[Sri Ranjan]

Hi,

We are facing this problem of issues getting strikedoff even when they are not in resolved/closed state. The situation we have here is we have "Resolution" field in in edit screens and in few transition screens and strike through is appearing when ever a issue is edited or any transition takes place. The only soloution right now i see is to remove resolution field from all the screens. Is dre any other better way available?? can i do something with the "Resolution" field dropdown so i will not have to modify my screens?? Please help.

[RambanamP · Accepted solution]

what is the necessity to add "resolution" field in all screens?

i think it should be there on resolved/closed screen.

create a transition called "Closed" or "Resolved" and configure screen with Resolution field.

[Nic Brough -Adaptavist-]

It is not necessary, and it is incorrect. As I already said, the resolution field is intended only for transitions that close the issue.

[Norman Abramovitz]

Somehow the resolution field is being filled in. Either the user is doing it or your workflow is doing it.

[Nic Brough -Adaptavist-]

You've answered your own question - the best "solution" is to use the resolution field as it was intended by design - do not it to add the resolution field to screens where you don't want to set it in the first place. It should only be on screens that are used when the user says "resolve issue".

[Sharon van Leeuwen]

Hi Guys,

Currently I am using Jira Service Desk Application 3.3.0-OD and we got a Zephyr plugin so that we can link bugs tickets to test cases. 

Unfortunately many bugs tickets that are not resolved get a stripe through. I still haven't found my answer here how to resolve the issue.

Current issue: We link bugs to testcases. Bugs that have the status DONE or CLOSED and resolution is changed to Done then the ticket get's a stripe through. Sometimes we use the status Blocked (it seems also this triggers a stripe through).

Now it seems to appear that tickets that are not resolved yet and are still open get a strip through as well. This makes it very confusing and therefore using Dashboards is not really working.

To what variable is the stripethrough of tickets linked? I have read resolution is linked to a stripe through, but in our workflow the resolution is a dropdown list so I cannot leave it empty. 

What can I do to keep tickets with the status OPEN visible without a stripethrough?

[Nic Brough -Adaptavist-]

Resolution.  It is nothing to do with status.

Issues without a strike-out have an empty resolution.  Issues with a strike-out have a resolution set.

The resolution could be any string.  You'll see things like done, fixed, won't fix, duplicate etc, and less often, more unusual words like prescribed, penguin, darth-vader.  The word is completely irrelevant to Jira all mean "it is done, strike it out".  Even the word "unresolved" used on that list means "resolved, so strike it out".

You must go into your system and look at where the resolution field is used on screens.  You should never put it on a create or edit screen.  It should only ever be used on transition screens where the status is changing from an "open" one (usually blue or yellow) to a "done" one (usually green)

[Sharon van Leeuwen]

Thanks for your reply. 

After I post this question, I found the answer in the feed indeed. I informed our Jira guy who was able to change the settings to amend the changes for resolution so that no single ticket will get automatically a input for resolution. 

Problem is solved with the stripe through now :)

[Jane Scolieri]

Actually, I just migrated the workflow of that project over to the Classic Workflow, and I now have what I want (I think.) When I hit Closed, I am given the option to input a resolution. I'll just use that workflow from now on. I thought the Software Dev workflow would be right for us, but I think we just need a basic workflow like this. Thanks for your patience!

[Jane Scolieri]

Nic, I created a screen which doesn't have the resolution field active and assigned it to Bug, Issue, New Feature and Task. I assign it to a screen scheme and an issue type screen scheme and then the Project. All good. Then when I try and step through the process with a test bug, I Click the transition IN PROGRESS, the Resolution is Unresolved (good). I pretend I fixed this bug and then I click Done. It still says Unresolved (but shouldn't I then have the option to edit resolution to say 'fixed'?). Then I only have the choice to click Reopen and Reopen and Start Progress, and Reopen and start review. So I click the last one as if I'm a QA person checking the programmers work, [although why I'm 'reopening' it is confusing to me.] Then I click Done, and it still says Unresolved. If I click 'e', no resolution field is present. So basically, where does that come in? Do I need to make another screen called editable-resolution-screen? Or is this a different problem, to do with statuses? Still confused. Thanks for your help.

[Nic Brough -Adaptavist-]

Ok, again, you've almost got there for yourself!

There are FOUR places you can use a screen - View, Edit, Create and Transition.

The screen schemes handle the first three, and it sounds you have got these spot-on now. You're using a screen without Resolution for Create or Edit. (View is a bit odd - some system fields, including resolution will appear on issue view even if you remove them from the screen, but as you're not able to edit on the view screen, it's fine not to worry about it). This solves the problem of accidentally setting a resolution when you don't really want to.

So, you've now got a clean process that doesn't set the resolution at all.

Which isn't quite right, but you are spot-on with "Do I need to make another screen?". Yes, you do. Add the resolution field to it.

The only bit you've not spotted is the workflow tie-in. Look at the workflow and decide where you want issues to be resolved. Let's say this should be the status "Closed" and "Resolved", like the default workflow. Now...

• For every transtion going INTO Closed or Resolved, put your new screen on the transition
• For every transition going OUT of them to an "open" type status, add a post-function where you "set field (resolution) to value (none)"

[Jane Scolieri]

I really need help with this. When an issue is created, the resolution field is forcing the user to select a resolution, obviously we don't need to have that happen at that point in the process. In addition, if the user selects 'incomplete' as that is the only slightly reasonable choice, the issue becomes strikethrough. Quick fix? Someone may have edited this incorrectly, and I need to get it working correctly without having to add a bunch of workflow, screen schemes, etc.

[Nic Brough -Adaptavist-]

You need to do two things.

1. Remove the resolution field from ALL screens except the ones that are used for transition from "open" type status to "closed" or "resolved" status

2. Delete the "incomplete" resolution, or rename it to something more useful like "we are never going to do this". Because any value in the resolution field means "issue is closed". Doesn't matter if you put in "unresolved", "still open", "incomplete", the fact that there is anything in the field means it is resolved and hence struck out and ignored by most of Jira.

[Sri Ranjan]

we are using Jira 5.2.. Sorry forgot to mention earlier.