Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Resolution status in Test issue different between imported and mannually created test Edited

So my company is recently using Jira and Xray. We have a workflow defined for all issues, including for Test issues. In this workflow we have a status that has a resolution of DONE associated. While going through the list of tests in a project, we noticed that some tests were in different status of resolutions, even though being in the same workflow status.

After some analysis, we found out that the ones marked as 'Unresolved' were the tests imported with Test Case Importer, that were imported already in the workflow status that is set as 'resolved'.

The manually created test issues, since they go through the several status in the workflow, when they are set into the 'resolved' state, the Resoltuion is the expected one DONE.

Any idea on why or how to solve this situation?

1 answer

0 votes

Welcome to the community!

"Unresolved" in the resolution field is usually not actually a value.  It is Jira finding the field empty and displaying "unresolved" to the humans, because that's what an empty resolution means - the issue is not resolved.  Any value in the field means "issue is resolved".  (Even if an inexperienced Admin adds "unresolved" to the list of options, that still means the issue is resolved, because it's not empty)

So, my guess would be that your test cases did not have resolutions to import, and they've come in blank, hence displaying "unresolved"

Resolution should be set in the workflow - cleared out with a post-function in transitions that are re-opening issues, and set by either a post-function or with a resolution field put on a screen during a "close" type transition.

To fix the test cases that have come in with no resolution, the off-the-shelf thing to do is to transition them through the workflow to an end state, assuming it has one of the two ways to set resolution when closing them.

You could also re-import, using the issue key of the test issues and a resolution column as the imported data

Or you could bulk-edit the issues - however, this is slightly risky - you have to temporarily add the resolution to the "edit" screen for the issues, search for them, select the ones to update and then set a resolution.  When complete, you must remove the resolution field from edit.  The risk here is that someone edits another issue that uses the same edit screen while the resolution is on it - they will inadvertently resolve any issue because the resolution field is on the edit screen. 

Thank you so much for your answer and how to solve the situation :)

But here you state:

"To fix the test cases that have come in with no resolution, the off-the-shelf thing to do is to transition them through the workflow to an end state (...)"

I put this question here exactly because the case is that the test case imported is in an end state of the workflow.

For example, my end state in the workflow - which is set in the workflow as resolved - is 'In Use'. I create a test issue manually, transition it through the workflow to the end state 'In Use', the Resolution becomes 'Done'. I now import a test issue, which in the csv to import I define that the issue will be created already in the workflow status 'In Use' (end state). The issue is displayed in Jira as 'unresolved'.

Why doesn't Jira recognize that the imported test issue is in an end state of the workflow and sets the correct/expected resolution?

Workflows are made up of two things - steps (each of which has a single unique status mapped to it) and transitions.  An issue is created at one step in the workflow and to change steps/status, you move it through transitions.

A step is a state of being, whereas a transition is an action (that changes the state of being).  Resolution is a field, simply holding data.

Resolution is an unusual field in that it is not usually edited directly, it is set by transitions, not entered by people (ok, they get to choose one in resolution screens, but that's still part of a transition)

The important thing here is that status and resolution are not only totally different things, they have no relationship.  Technically.  Logically, of course they do, and it's something we always talk to new admins about so they know that part of their job is to define that relationship correctly.  But there is no coded link.

In every Jira system on the planet, you could tell me what a status is (translating it into English so i know what it means) and I would not be able to tell you whether the issue is resolved or not.  If it should be, yes, most of the time, but because resolution and status have no coded relationship, there is no way I could tell you whether the resolution is filled or not.  And vice-versa - given a resolution, and even a list of status available in your system, I have no information on what the status of an issue is.

When you import issues, you can tell Jira what status they should be imported in, but they go through no transitions to get there, so even if you've built your workflow to handle resolutions correctly, Jira has no way to know that they should be resolved.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you