Mark Jira Task Resolved

[Seth Dunn]

Hi-

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?

Thank you!

[Nic Brough -Adaptavist-]

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.

[Denis Mullaraj]

Great answer! I have the transitions IN setup but I don't understand how to achieve the "clear resolution" with transitions OUT

[Nic Brough -Adaptavist-]

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"

[Denis Mullaraj]

@Nic Brough -Adaptavist-

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

[Nic Brough -Adaptavist-]

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.

[Denis Mullaraj]

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-]

You'll need Apps to provide either a scripting framework, or to provide the listener itself that can do it.

[Denis Mullaraj]

So in anyway I need a plugin for it in case I am using Jira Cloud? If so, which one would you recommend?

[Nic Brough -Adaptavist-]

On Cloud, you're more restricted.  I would have a look at Automation, and I think ScriptRunner can do it (but I don't think there are any Apps directly provide a function like this)

[Denis Mullaraj]

Thanks Nic!!!

[Denis Mullaraj]

@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?

[Nic Brough -Adaptavist-]

Your workflow doesn't have a valid transition for what you're trying to do.  You'll need to add one to it.

[Denis Mullaraj]

How can I check that? It does work for stories, but not for that Task. Although I have 2 workflows, one for Subtask and another one for the remaining issue types (task, story, bug...)

[Nic Brough -Adaptavist-]

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.

[Denis Mullaraj]

@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 :)

[Sofia Castaneda]

. 

[Peter Van de Voorde]

Hi Seth,

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 :

https://confluence.atlassian.com/display/JIRAKB/How+to+Edit+the+Resolution+of+an+Issue

And about workflows here :

https://confluence.atlassian.com/display/JIRA/Configuring+Workflow

Best regards,

Peter

[Michael Ward-Murphy]

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

HTH,

Mike.

[Michael Ward-Murphy]

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

[Nic Brough -Adaptavist-]

Argh, no!

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.

[Mike W-M]

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.

https://answers.atlassian.com/questions/253817/answers/42684247/comments/42686187

[Nic Brough -Adaptavist-]

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

• a transition screen that contains the resolution, so the system asks the user to tell it what resolution to use
• or, when they know it's always the same resolution, or don't actually want to trouble the users with it at all,  a post-function that sets it (a good example would be "it's a duplicate, close it")

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!

1. JIRA's default workflows were built by good admins and handle resolution fine (By all means change them, but they are good starting points and use them for examples of how to handle it!)
2. The possible values of resolution are global and listed in Admin -> Resolutions.  You can add/edit/remove the list, but the default list contains values like "fixed", "done" and "won't fix" already.

[Michael Ward-Murphy]

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:

 image2016-9-29 23:35:54.png

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.

[Nic Brough -Adaptavist-]

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.

[scherbank]

You can try Jira Simplified workflow. It is much easier to configure and set resolution. (also add \ remove statuses and extra).

[Seth Dunn]

Thank you for the help!

[Norman Abramovitz]

From the terminology, do you know if you are actually using Jira Agile? If so, marking an issue Done is all you need to do. If I am guessing correctly search for Jira Agile simplified workflow for more details.