I would like for Resolved Date to ONLY populate when resolution is manually switched to "Resolved"

AFTER issue creation, regardless of workflow, screen scheme or project, every time the issue is EDITED, the "RESOLVED DATE" is automatically populated and there is some automated change made to the Resolution status. 


image2017-3-16 15:4:52.png

1 answer

You should check the following in the first instance. 

  1. Do you have a custom resolution called Unresolved? If so this should be removed.
  2. Do you have the resolution field present on your edit screen? Again if so this should be removed.

You may need to do some remedial action to clear the resolutions that have already been set to Unresolved through editing. The simplest way to do this is to add a clear resolution step in a self referencing workflow action for all statuses.


1) No. (please see attached screenshot).

2) By removing the resolution field on the edit screen, how would you propose to "manually push" the issue into a "Done" status? Through a post function on a workflow?

 When the issue is created, it is automatically set to "Unresolved" - my concern is more with the automatic population of Resolution Date

image2017-3-16 16:8:37.png

Your answer to 1) is wrong.  The screenshot clearly shows that you have added an "unresolved" resolution to the list. 

There's a couple of things you need to do.

1) Go through all your screens.  Remove the resolution field from any screen other than resolve transition screens

2) Rename the broken resolution to "do not use" or something equally clear

3) Run a search for all issues where the resolution is now "do not use" and compare with the status to assess the damage.  Ideally, filter for that resolution, save it, and use it in a "filter statistics" gadget to see where it has been incorrectly used - use the issue status to see where it's acceptable and wrong.


1) I went through all screens and removed the resolution field called "UNRESOLVED"

2) I renamed it to DO NOT USE

3) i only have 29 issues that were impacted by this status - the "UNRESOLVED" setting has been correctly used on all of these issues.  

but here is where i think you missed it - my problem is not issues sitting in an "UNRESOLVED" status – its the ones where we are still working the issue and then for some reason during editing, the issue automatically generates a "Resolution Date" which is screwing up the reporting.  


Please look at my first screen shot - you can tell that 3 things are happening:

1) I adding a due date AFTER the issue has been created (in the view/edit screen)

2) the "Resolution:  Unresolved" field is NOT BEING MODIFIED IN ANY WAY

3) the Resolution Date is automatically populating once the edit has been saved.

This is causing issues to appear resolved on a particular date when, in fact, they are still being worked by my team.

Thoughts? Am i completely out of my mind?

I am sorry, but this makes no sense:

>the resolution field called "UNRESOLVED"

There is a field called "resolution".  Not unresolved.



I apologise for not making the linkage clear.  You have a broken resolution value.  The resolution date gets set when you use any resolution value, including the broken one.  You have a problem caused by having a broken resolution.

I'll slow down and do this in smaller steps

  1.  Go to Admin -> Issues -> Resolutions (the screen in your second screen shot)
  2. Edit the value on the line that says "unresolved", setting it to "broken" or "do not use" or something that works for your users to tell them it's wrong
  3. We need you to remove the resolution field from the screens.  Not unresolved.  Remove the field from the screens, not talk about options. 

Okay, i think i get it now.  All the screens have had the resolution field removed.  So what should i do with the 29 issues that have this broken resolution on them? 


image2017-3-16 17:12:43.png

Ok, great,

For the 29, filer for them and look at their Status.  What you're looking for is a general feel for how badly broken they might be.

If all of them are in a status that means "we're done" (usually coloured green), then it's easy because you can go back to the list of resolution values, delete "do not use" and the issues can be swapped to "done". 

If they're all in an open status, it's a bit more of a pain, because you need to clear the broken resolution out.  For 29, it's probably going to be easiest to push them all through a trnasition that has the post-function "clear resolution" on it.

Okay, so new wrinkle - there is another "Unresolved" resolution type out there but i can't seem to get to it.  


Also - none of my workflows that ive made have transitions that include the post-function "clear resolution" - would i be better off just cloning the issue and delete the defective one?

image2017-3-16 17:23:47.png

Ah, no, but maybe.

I think that's the system display, not an actual resolution.   So I suspect it's fine.  You can check in advanced search by comparing the queries "resolution is empty" with "resolution = unresolved".  For a healthy system, you'll get the same number.

We've not really covered the background too well here, so here's a shot at it:

JIRA has a resolution field.  This is a list of options you can select from. 

When the field is empty, an issue is considered "unresolved", and JIRA displays unresolved, rather than an empty space.

When the field is filled, with any value from the list of possible options, then the option is displayed, and the issue is considered to be resolved.  Even if the option says "unresolved", it means "resolved", because that's a value.  (It really could be any value in there.  If it contains fixed, done, resolved, unresolved, horde of penguins, Hodor, empty, Mr Flibble, done, thingy, asdfasf - the wording is irrelevant, they all mean "resolved" when looking at the boolean resolved/unresolved flag)

The resolution date is "when the issue changed from unresolved to resolved"

First, you have been v v helpful so, thank you.  

Second, i had to google Mr. Flibble but now i have costume ideas for October.  

Third, i now have an opposing problem because the system is not filling the field even when i am pushing the issue into a green, "completed" status on the work flow. Is the only cure for this to use a post-function on the workflow by editing Generic Event to say "Issue Resolved?"  


image2017-3-16 18:55:37.png



>First, you have been v v helpful so, thank you. 
It's no problem.  I'd also thank you for being responsive, feeding back and thinking clearly about how to answer the questions I've thrown at you.

>Second, i had to google Mr. Flibble but now i have costume ideas for October. 
Remember that Gingham is impervious to hex-vision rays.

>Third, i now have an opposing problem because the system is not filling the field even when i am pushing the issue into a green, "completed" status on the work flow. Is the only cure for this to use a post-function on the workflow by editing Generic Event to say "Issue Resolved

You're very close to the right answer there, but the event is a "red herring" (which I'm sure Mr Flibble would see as a tasty snack).  The event is there to trigger emails and for "listeners" to pick up.  I know why you looked at it for resolutions, but it is not the right place.

There are two options for your "Close out" transition.  You have intuited exactly the right thing - when the transition is complete, you need the resolution field to be filled in.  So, you can do one of two things (do not do both, it narks your users)

  1. Choose a "screen" for the transition, and make sure it has the resolution field on it (because, as we talked about above, it will get set, even if a user ignores it).  Disadvantage - needs users to choose right, or ignore it and get a default value.
  2. Edit the transition and add a "post function".  Select "set issue field", then "resolution" and any value other than <none>.  Disadvantage - will always be the same resolution.


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

244 views 6 0
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