issue id strike through when issue is not resolved

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.

7 answers

1 accepted

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.

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

1 votes

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".

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

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

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.

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.

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.

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)"

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!

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,739 views 11 18
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot