How do I remove resolved date when erroneously populated

[Andrea Janoo]

I am working in JIRA 6.4.  The issue I have is that the resolved date is populating on JIRA tickets in a couple of scenarios across 2 projects that have a similar workflow:

1. The ticket is created

2. The ticket transitions from one state to another

The date populated has been both a transition date and created, and recently when a ticket is moved from one project to another in the same instance, the original created date of the ticket is populated on the JIRA.  

I have tried bulk updating, importing resolved as blank and I have put a 'purge field' in the post function at each stage and have had no luck resolving the issue.  Any insight would be greatly appreciated

[Petter Gonçalves]

Hello Andrea,

Welcome to Atlassian Community!

I must confess that I did not understand exactly what caused your issues to have a wrong Resolved date populated, however, please allow me to give you some concepts about this feature so we can confirm we are in the same page here:

The resolved date is automatically updated in Jira issues when you set a resolution for it, and a resolution must be set only when the issue is transitioned to the last status of the workflow ("Done", "Closed", etc.).

That being said, the only way that would justify the resolved date of an issue to be corrected would be if the issue was transitioned to "Done" without being Done, by a mistake of the issue assignee. That was what happened? 

If that's the case, there are two ways to update a resolved date that was wrongly set:

1 - In case the issue is still not solved, you can simply reopen the issue and resolve it again when the time comes, so the issue will be set with the correct resolved time.

2 - In case the issue is already resolved by was wrongly transitioned to done before it was effectively resolved, you can import the correct resolved date using CSV import, as described in the documentation below:

Importing data from CSV 

P.S: 6.4 is a very old version of Jira, so maybe the steps above might not be applicable to it.

Let us know if this information helps.

[Andrea Janoo]

Thanks Petter, in the usecase I have, the resolution for the tickets are 'Unresolved', yet the resolved date is still populating.  The issues are truly in an open state according to the status of the ticket but with the resolved date populated.  I also tried a CSV import last week and this did not work either.

These were my go-to steps, but this has still not fixed the issue which means reporting and dashboarding is not behaving as expected.  

I would be grateful for any other suggestions you may have (which avoid the need to re-build the workflow) if you have any other thoughts!

Thanks in advance

[Petter Gonçalves]

Hello Andrea,

Thank you for your details.

About this statement:

the resolution for the tickets are 'Unresolved', yet the resolved date is still populating.

I saw this behavior before when a valid resolution was created with the name "unresolved", causing a big confusion where the issue is resolved but displaying the "Unresolved" text in the resolution field, which is the same text for when the resolution was not set yet.

That being said, I recommend you to try the following steps to diagnose it:

Navigate to Jira Settings > Resolutions (Or type GG and resolutions) and check if there is a resolution called "Unresolved".

Additional to that, you can use the following queries below to see what issues are configured with the wrong "Unresolved" resolution:

resolution is not empty and status !=done

if the query above return any issues, I recommend you to follow the steps in the documentation below to properly fix it:

Bulk edit resolutions in Jira server 

Let us know if this is the problem you are facing.

[Amanda Culver]

I have the same issue as @Andrea Janoo

The issue was created yesterday @ 23:37

It was transitioned from the start state to a second 'To Do' state,

then a third 'In Progress' state.

It has a resolved time equal to the start time - 23:37.

[Souvik Nath]

I also having exactly same situation like @Amanda Culver