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

[Thomas Hardin]

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]

Hi Thomas,

Could you tell us more about your instance of Jira, such as what version of Jira is this?  And what specific steps are taken in your environment in order to create these child issues?

Perhaps I'm missing something else here.  Are you by chance cloning the source issue here instead of creating a subtask of it?   If so, this isn't something I would refer to as a child object exactly.  In terms of parent-child relationship between issues in Jira, in my experience this only refers to the relationship a subtask issuetype has with its parent issue.

When I first read your description, I tried to resolve different issues in my Jira instance and then create subtasks of those issues.  In my attempts, none of my subtasks inherited the resolved date of the parent issue.   So then I thought perhaps you are referring to the clone function, but again, at least in my Jira 7.9.2 version, cloning a resolved issue did not cause the cloned issue to have any value in the resolved date field.

So please let me know some more details about your environment so I can investigate this further.

Thanks,

Andy

[Thomas Hardin]

We are using 7.5.1 and this is what I am doing:

1. I have a single request that provides users with the option to select additional actions where they choose options from an additional actions field.

2. The options represent other issue types, which are created using the Create Issue post function from JMWE workflow add-on. There are up to 11 options, each representing an issue type.

3. Each issue type created is set up so that it blocks the main issue type. Conditions are set to restrict the issue from being closed until all related issues are closed. When the first issue (child) is moved to Open, then the main issue (Parent) is moved to Open.

4. The child issue types all have a Resolved Date set. Before I arrived, the administrators did have Unresolved as a Resolution. I have removed that. I thought that would have corrected the issue, but it did not. So, I had to set a Clear Field post function on the Create transition so that it was clear the date. I actually had to place this before the Create Issue Post function as it did not work as Step 2.

I hope this helps.

[Andy Heinzer]

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. 

[Thomas Hardin]

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]

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.