Is there an open Bug for the Resolved date being populated on child issues?

Question

I have been reviewing posts on the community site and see that a number of Atlassians have had issues with the Resolved date being populated with data, yet the issue had not been resolved.

We've encountered something similar where we are using a parent issue with an actions field to generate other child issues based on the selection a user makes. This is pretty straight forward, yet we notice that the Resolved date was actually populated on the child issues.

We implemented a Post Function to clear the Resolution field for the child issues; we also learned that we had to make this the first post function, before the Create issue action. This works as expected, but I didn't know if this  approach was considered a permanent solution or if Atlassian was working on one.

Can anyone steer me to some documentation supporting this approach or let me know if a more permanent solution is in the works?

Thanks everyone!

Andy Heinzer · Answer

I can't see a way to keep the resolution field required and still correct this.  Jira is using that system field in a specific way where any issue that has ANY value at all for a resolution field is being considered resolved.  That is the intention of this system field in Jira.  As such issues that are resolved will appear on a Agile board with a strikethough on the issue key and description, or the issue could be marked as closed within a Service Desk customer portal, or can be hidden from a kanban board with the default subfilter that hides resolved issues, and so on.   There are other functionalities within Jira that are expecting that field to be empty (and have a null value in the database) for issues in Jira that are not yet actually resolved.   Only when the issue is actually resolved, is it expected to be given a resolution value, and in turn it gets a resolved date when that value is set.

When administrators make that field required in the field configuration, it forces the end users to enter a value for that issue when it is created in Jira.   This is why those admins create these other resolution values such as 'Unresolved', 'not resolved', etc.  Rarely is that actually useful because when you create an issue, it's almost never resolved immediately.  And setting a resolution value on an issue in Jira is prematurely showing the issue as being resolved or completed.

I would recommend trying these changes on a test environment first.   There is another related KB that can explain how to correct this setup.  Please see Closed issues show as UNRESOLVED or open issues appear as Resolved with strike through.   It also provides two different ways to correct this.

Thomas Hardin · Answer

Since this value is present in our other environments, Test and Production, what do you think the best option is for correcting the issue before I migrate changes? I was lucky enough to find this issue in our development environment first.

The customers want a value that represents the issue as not being resolved (I've convinced them to use "Not Resolved"), however; they have 100s of issues that have closed and need to be updated. Do we change the value of "Unresolved" to "Not Resolved" in each environment? Or, do we create a new resolution value or "Not Resolved", then do a bulk change for issues with "Unresolved" that have a Resolved Date?

Also, for the field configuration scheme, the Resolution needs to be required. Luckily the issue types are all on one project. Is there a way to keep it required and fully correct the problem?

Thank you for all of the help.

Andy Heinzer · Answer

Ah, yes that does help.   I think what is happening in your environment can also be explained by this KB: https://confluence.atlassian.com/jirakb/unresolved-showing-up-as-a-resolution-for-resolved-issues-163938438.html

You mentioned that the Jira Admin had created a resolution called 'unresolved'.  I typically only ever see this when the admin has changed a field configuration scheme in Jira in order to make the system field called 'resolution' required.  When you do this, Jira requires that this field have a value at all times for all issues in that field configuration, from the beginning of the issues creation, all the way through to the end.

This isn't how that resolution field was designed to be used in Jira.  Instead, as a system field, this particular field on issues is a NULL value by default.   In turn Jira would display an italicized value of Unresolved if the issue had no true value for that field.   I am afraid that simply removing the unresolved resolution type won't be the sole solution here, you would also need to adjust the field configuration scheme in use by all the child issues to make the resolution field not required on the field configuration.

Only then can you create issues in that project without them being forced to contain a resolution value on creation.