Our current process is for our Product team to be the one to close the parent task. We have several other people without our company handling sub-tasks and any one of them could be closing the final sub-task to receive this pop-up. We can ask that they ignore this, but we cannot guarantee it. We would prefer to have the option to remove this by board or by project.

I see this issue is closed, but there is no resolution. Please re-open or provide an update on a work around.

@nathan script works great!

Agree with others over. There is no point in this popup as people who want similar behaviour can add it in the workflow.  This popup just confuses our team and leads people to set the story to done when they have not checked the acceptance criteria.  

I think for most cases this issue is solved in JIRA 7.0.5 with GHS-6499 (see Release Notes). At least for us it is sufficient to limit the rights to close an issue/story to the group of Product Owners. With JIRA 7.0.5 all other users don't see any "close parent" dialog or error message. The transition will just not be performed, and the PO is able to close the issue via the "Move to done" button in the sprint backlog.

I did the following to make this go away:

1. Install Script Runner (sorry, it costs money now)
2. Add a simple scripted condition to your "closed" transition for the parent issue
3. Use this code:

   import java.sql.Timestamp;
   import java.util.Date;
   
   java.util.Date mydate = new java.util.Date();
   long mytimeinmillis = mydate.getTime();
   
   for(subTask in issue.getSubTaskObjects()) {
   	if(subTask.isSubTask()){
   		Timestamp resolution_date = subTask.getResolutionDate()
   		long rdateinmillis = resolution_date.getTime()
   		long millisdiff = mytimeinmillis - rdateinmillis
   		if (millisdiff <= 1000*3){
   			//a subtask has been closed within the past three seconds, don't allow the parent to transition.
   			return false
   		} else {
   			//do nothing
   		}
   	}//if it really is a subtask
   	
   	
   }//for loop
   return true
   

Whenever you close a subtask, it will temporary disable the "Closed" transition of the workflow for the parent issue for 3 seconds, which is long enough to block JIRA from displaying this popup (since the transition isn't valid, JIRA will never display the popup).

Wow, another example of Atlassian totally deprioritizing a simple win that would remove a major annoyance. How hard could it be to add an admin checkbox to disable this feature and they won't even keep the request open for consideration.

Isn't it obvious that there would be a TON of circumstances where a top level issue has workflow steps to complete even after all the sub-tasks are closed?

I only discovered this "feature" when I "fixed" my Done column. Previously I was using a Agile Board filter that had "resolution IS EMPTY" as a clause and so the Done column was always empty and in that case this feature was never triggered. I recently changed the clause to "(resolution IS EMPTY OR resolutiondate > -1d)" so that the Done column would show recently resolved issues and now users are complaining about this "feature". My fix will probably be to re-break the Done column rather than relying on a hacked header.jsp.

I encounter the same problem here.
Using Kanban process I use a post-function that transitions the Parent issue to a different status than DONE when all the tasks are cleared. The "auto-transition" works, but I still have the error window who show up.
Is it possible to disable this feature from Jira-Agile (Greenhopper) in the Cloud version?

What resolution to this?

This ticket was Closed with a resolution of "Answered" on July 24th, but I don't see an answer to anything regarding this issue.

Please reopen this ticket and allow voting to continue as this really should be a configurable setting and I am sure many will agree/vote.

Thanks for your support!

I've recently downloaded JIRA and I'm trying to customize it to meet my needs. Turning off this dialog is one of the requirements.
This can't be so difficult to allow user to disable this option.
Please reopen this issue and consider this functionality.