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.
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".
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...
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!
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hi Community! My name is Amir and I’m on the Jira Service Desk product marketing team at Atlassian. Our team would love to understand how you’re leveraging our ecosystem for Jira Service Desk. Wha...
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