My company has recently started using Jira to manage some of our development projects, so I'm relatively new here. My question is this:
How does one mark a task as "Resolved"? I am able to change the workflow status from "In Progress" or "In Review" to "Done", but I cannot seem to change the Resolution status to "Resolved". Is there a setting somewhere that enables this that I'm missing?
You'll need to fill in the Resolution field to mark an issue a Resolved in JIRA.
The resolution field is normal found on the default screen you are using to create an issue or to edit an issue.
If you want to add extra steps to your workflow then this is possible using the Workflow editor.
More information about resolutions can be found here :
And about workflows here :
Please don't use the phrase "resolution status" - it's confusing and wrong because status and resolution are two different things. Ask yourself what you actually mean by it?
Status is where your issue is in its workflow.
Resolution is a flag that tells Jira whether the issue is to be considered "resolved" or not. If this flag field is <empty> then the issue is unresolved (Jira will display "unresolved", although there is actually nothing in the field). If it is set to *anything* else, then the issue is "resolved" and Jira will drop it from standard reports, show the issue id with a strike-through and so-on.
The workflow usually ties these together - in transitions IN to status where an issue should be "resolved", they either pop up a screen with the resolution on it and require the user to set a resolution, or they set it to a fixed value in a post function. Transitions OUT of these status then have "clear resolution" to remove the value.
It sounds like your workflow has dropped these functions. You need to add them back in, then you'll need to reopen all your resolved/closed issues to set the resolution. Or, you can add a transition from "closed" back to itself which sets the resolution and use bulk-edit to go through it.
Edit the workflow, and amend each "OUT" (of closed) transition. Add a post-function to each, selecting "update issue field", select resolution, and then none for the value at the top of the list. When saved, it should display as "resolution will be cleared"
That worked out. Thanks! How can I set as well the STATUS to be updated? What I mean is, when I move subtask from DONE to TODO (when I move it back for example) I want the Parent Issue of the subtask to update the status as well. I have already 2 workflows for subtask issue type and all other issue type but I can't see in the transition of the subtask workflow a post function to update the status of the parent issue...
Status is changed by running a transition on the issue.
If you want to change the parent issues, you'll need code or a script that can trigger the transition you need to do on the parent. I'd strongly recommend using a listener for this, and it could be complex, because it's going to have to think about every possible state the parent is in, and have a transition to execute to take it to the new status.
Thanks for the quick reply Nic! It seems like a good idea, is that possible for me to use listener or is that possible only with plugins? I would like to achieve that without plugins as they cost money and I would like to try the free way before. Is there any article out there about the "listener" way and how to handle this?
@Nic Brough [Adaptavist] Last thing, How can I manually move transition the parent issue to a status?
I have a Task issue type in the sprint, I have one subtask for it, although the subtask has moved to Done swimlane the Task Issue Type (which is the parent) is in the "In Progress" swimlane.
I have 5 swimlanes: Todo, In progress, Code Review, QA, Done
I tried to double click on the parent issue type to search for something like solve, resolve, close, mark... but no option. I can't mark it as done. Why?
Edit the workflow and look at the transitions that take an issue from one status to another - use the "columns" tab in the board setting to see where each status is in the board and hence which transition takes an issue from one column to another.
When you've identified the transition you need, look at the "conditions" tab in the properties box that pops up when you click a transition.
Or, add a new transition if you need one, and make sure the conditions don't block your account.
@Nic Brough [Adaptavist] Ok great I found it, I just had to open the issue in full screen instead of the preview pane on the right and on top I could click on Transition to progress, and then transition to other statuses. I got confused by the new jira cloud. Sorry and thanks for the great support! Definitevely I will remember your name when I have any issue on jira :)
JIRA newbie here on 7.2 Software, so YMMV:
I created some projects using the Basic Software Development template and found, like you, that I can't edit the resolution field (either before or after setting the issue to Done - and what is this transition screen that people speak of?).
The reason seems to be that the field isn't by default included in the list of fields in the "Field Tab" of the (Project-code:) Software Development Bug Screen and the project's Default Issue Screen. Go in and add "Resolution" into these lists and it magically becomes editable!
(Start on the /secure/admin/ViewFieldScreens.jspa page and click on the "Configure" link for each screen to get to the page I'm talking about.)
...although having had a bit of a play, it does appear that you might be able to get status and resolution out of step like this - so maybe editing the workflow is a better method.
This seems extremely unintuitive default behaviour for a "software project" to me - I'd have thought the ability to "end" an issue with a "resolution-status" of "Won't do" (already configured but unavailable) would have been a no-brainer.
Do NOT add the resolution field to any screen other than transition screens. This is exactly how a resolution becomes out of step with the process flow. Your users will set a resolution on any create/edit, even on "open" or "in progress" issues.
Well, strictly speaking, it's already on the screen - just frustratingly uneditable.
It appears the default set-up is not offering me a pit of success: I haven't seen a transition screen yet, and I would guess that I'm going to end up with issues where the status status has been set to "Done" and then someone's added a "Didn't fix" or "not an issue" to the comments. (And that's worse than the out-of-step option, assuming you can still query the 2 fields to detect the mismatch in those.)
Everybody knows a software issue tracker has to have a "Won't fix" option available, because every public issue tracker always has the bug or feature you're needing set to that status.
Ah, sorry, no. "Screen" here means "a named list of ordered fields to be presented to the user at a certain time when they do something with an issue".
They're used for Create, Edit and (multiple) transitions. There is also a View screen, but this does some rearranging of stuff - even if you give it a short list of fields, it will always display the "system" fields, such as status, assignee, key and, of course, Resolution.
The view, edit and create screen selected are determined by the "issue type screen scheme" for the project. The transition screens are set in the workflow. You can tell any workflow transition to use any one screen you've pre-defined - when a user triggers the transition, they'll be presented with the fields listed on it. Or leave it empty so transitions happen with no interaction.
Do not mix up status (where an issue is in the workflow) with resolution (an issue is done with, and here's why). They are different things - instinctively related, as you'd expect any open issues to have no resolution, and issues you've finished with should have one, but technically, there's no automatic link between them. This allows poorly built workflows to set or clear resolutions at the wrong time, which then looks odd because you can have an issue that is (status) Open, and yet (resolution) Won't Fix.
A good JIRA admin will always build workflows that handle this relationship. As a general rule, a good workflow will set a resolution when moving from a blue or yellow category status into a green category status. They will do it either with
Then, in reverse, when re-opening an issue, they'll use a post-function for "clear resolution".
Now, two more points before I run out of space!
Nic, thanks. (Don't forget you've got a day job!)
I understand what you're saying and I think that much of it's intuitive having seen any other issue-tracking system or indeed just an Excel spreadsheet (or 50) that tries to track issues. However, much of it is at odds with the default "workflow" that I get when I choose to create a Software project, which as far as I can tell is the one pictured here:
This seems to give me the ability to skip between any statuses at will (and I guess purists might argue this is wrong - but if you're coming from an Excel spreadsheet, it's right) but it doesn't seem to give me any resolution options for Done. (Which is wrong.) (Interestingly, if I've made that resolution field editable and set it to a value, when I change the status (at least out of Done) then the resolution does get auto-blanked. Not sure where that info's held... but I'm not asking you to explain everything to me!) Cheers.
Heh, I have a time-sheet code to log Answers against
My feeling is that the Resolution/Status thing is not as intuitive as it should be, but I do understand it's an inheritance from JIRA 1. I could ramble about this at length (although the short version is simply "make resolution mandatory for going into any green Status with a simple "ask user, or set it to X" option, always automatically clear it on the way out of green" and be done with it, although "edit" needs some thought)
With the workflow you have there, it's setting it for you. If you edit the All -> Done transition though, you can add a "transition screen" and ask the user for it, and hence get the prompt. But, do not put resolution on an edit screen. It will set the resolution when a user edits the issue, irrespective of status.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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