@Michael Tokar Please reopen this ticket.

At the very least please take a data-based approach, do some digging into analytics, and report back with actual numbers of how often people see the modal and decide to close the parent task vs how often they close the modal without closing the parent task.

If the numbers point to the modal actually being used to close the parent ticket >50% of the time (and probably a slightly higher bar than that, considering how often I've accidentally closed the parent issue) then so be it.

But my hypothesis — based solely on how our process works at my job — is that the data will show the modal being closed without closing the parent task.

In our case, we use subtasks to track small chunks of work on a ticket, but the parent ticket itself holds all the acceptance criteria. As such, once all the subtasks are closed we generally pass the parent task along to the reporter of the ticket so that they can review it. We don't want the parent ticket to close right away because it still needs to be signed off on. In fact can cause issues with SOX compliance for the ticket to be closed without first being signed off on.

mtokar  How can this be resolved? Is it answered because a workaround is available? The workaround might not be suitable for everyone due to not having script runner or it might not even work, Not to mention this is a requested change and should have gone through a  'gathering interest' state based on your feature policy.

In short, the workarounds don't work for our situation and this needs to be reconsidered. 

Jira server Jira v8.3.4

It really annoys the hell out of our users, as we rely on linked issues that has the 'blocked by' link type to be close as well, and not just sub task. The workarounds are all quite an ugly hack.

I was frustrated by the same issue. That's essentially a Post Function that is running that we cannot control and is not visible in the list of post functions. Naughty.

Here's an easy workaround to at least disable the modal so your team can avoid spending time on an unhelpful modal that actually tempts them to update to the incorrect status:

1. Make a copy of your Story workflow so you can edit it.

2. Edit the copy of your Story workflow so you cannot get to DONE without passing through READY TO ACCEPT (or whatever your desired pre-DONE state is). For me, I removed the ability to transition to DONE from ALL other statuses.

3. Save the changes.

4. Swap your story workflows and Publish.

5. Test. When you complete all tasks on a story, the modal to Update Parent Status to DONE should not appear.

How was this still not addressed more than 5 years later? As all the other commentators before, we need to disable this popup for our workflow! Please solve this issue.

As far as I understand, we need to restrict permissions to transition parent issue - so that when closing sub-tasks, there is no Pop-up. Is that correct 

How have this been resolved?

I agree with @Paul. I am going nowhere after reading all the comments. 

@Sascha - I have the same issue. Did you figure out the solution ? 

Hey guys... Kind of not very useful that this was marked as resolved @ 08/Feb/2018 6:13 PM, suggesting that there has been a feature released to support the suggestion, but no indication of what has been released.

Can we perhaps get some clarification on what exactly has been done for this issue, please?

Thanks,

Paul

this automatism triggers the wrong transition (Cancel). How can I set the right one if it's not possible to get rid of this mask at all?

In 7.5 version, at least you can choose if you want to transition or not. 

Please reopen the issue as we can vote for it.

In our case, the parent issue is moved to "Cancelled" without showing it to the user because it is the only "Done" status available from the current status in the workflow.

So moving the subtask to "done" moves the userstory to "cancelled", can you accept that ? or do you think it's a normlal behaviour ? as a JIRA user i don't think so.

I can see several ways to make this feature more "flexible"

1) Display the target status for parent issue in the popup (it is the minimum ;o) in order to show what JIRA will do the for the user

2) Add a disable option at a global level

3) Add settings in the sub-task transition to disable the popup or force to a specific "Done" status 

....

And i'm sure everybody can bring many ideas to give this feature more usability.

Thanks for understanding

There are indeed different acceptance criteria rather than all subtasks being ready. And also, having subtasks ready do not mean that I want the task to be ready, I maybe just want it to go to the next step in the task workflow (which is different than the subtask one).

We need to have the option to configure this feature differently, or at least be able to disable it.

The feature today is not good.

This functions would be great if we could manipulate the status the standart type would go! Or, at least, disable it.
In my case, it's moving it to cancelled when I try to use!! 

My user is not able to vote, but I'd definitely vote for changing this function

This feature is horrible, it should be removed. I would vote for this ticket if I could.

@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.

This dialog is frustrating, it is easy to a new developer to make mistakes and mark issues as done and as others have stated completing all sub tasks shouldn't mean the parent is done and accepted.

I'm using JIRA Cloud I can't even hack a file to disable it.

It would be nice if you, Atlassian, give your point of why it is so import to have this dialog even for projects where it is not useful.

Jake Fisher's description of why this should be changed is the same as we would like to implement. Atlassian: please reconsider - why is this not a post action that is added by default but can be removed?

@Atlassian
Please read carefully Jake Fishers comment. It explains clearly why this dialog box does not make any sense in an Agile world! Please let US decide about Definition of Done!

I agree with the comments above mine. In most of the cases this is absolutely inaccurate. In our implementation the sub-tasks have completely different workflows from the parents and therefore the parents even don't have the status. Please make it possible to disable acknowledge popups in this instance and in general.

I agree that this should be disabled, C. Ross McKenrick sums up my position perfectly

This should be reopened for voting and reconsidered for implementation by Atlassian. I completely agree with Scott Ocamb. As an agile coach, I teach that a story is done when the tasks are done AND the team agrees that the Definition of Done (for all stories) has been met AND the product owner agrees that the acceptance criteria (for this story) has been met. I use a four-step workflow for stories (Not Started->In Progress->In Review->Done). When the first task goes in progress, the story goes to In Progress. When the last task is done, the story goes to In Review. This is an indicator that the Product Owner needs to review the story and ensure that the Acceptance Criteria has been met - in which case the story is transitioned to Done. We've implemented (via code) the automatic transition of stories from Not Started->In Progress when the first task goes in progress, and the automatic transition of stories from In Progress->In Review when the last story is done. But this annoying prompt is confusing our team members and fighting our agreed upon practice.

For now I was able to edit the header.jsp to turn this off link see this answer title

I agree and propose this issue be reopened and reconsidered

I would have voted for this if it was available.

Would have voted for this if it wasn't "resolved". The dialog annoys me, I only ever dismiss it. Other members of the team are frustrated when it appears and hit OK without reading it, and don't realise they've accidentally transitioned the parent issue. Surely it's not hard to add a checkbox to indicate whether or not you want this dialog.

I believe the popup can be easily taken out as the user itself can mimic the same behaviour with the workflow.

For example:
On the parent issue, make sure the in progress to done transition is blocked if not all subtasks are closed
On the subtask issue, transition the parent issue from in progress to done

As long as not all subtasks are closed, the parent issue will not be transitioned. If you close the last subtask, all subtasks will be closed, the condition will pass and the parent issue will be closed.

The advantage of this method is that you give the user full control to do what he wants. Now Agile restricts me. Well actually it promotes the users to do an undesired transition.

++ Completely agree. Ross stated it well - the team agrees on definition of story Done, not JIRA.

thanks

I agree and propose this issue be reopened and reconsidered. The person completing the last sub-task isn't typically the person who "owns" the parent (e.g. Story) issue.

Thanks

This should be reopened for voting and reconsidered for implementation by Atlassian. I completely agree with Scott Ocamb. As an agile coach, I teach that a story is done when the tasks are done AND the team agrees that the Definition of Done (for all stories) has been met AND the product owner agrees that the acceptance criteria (for this story) has been met. I use a four-step workflow for stories (Not Started->In Progress->In Review->Done). When the first task goes in progress, the story goes to In Progress. When the last task is done, the story goes to In Review. This is an indicator that the Product Owner needs to review the story and ensure that the Acceptance Criteria has been met - in which case the story is transitioned to Done. We've implemented (via code) the automatic transition of stories from Not Started->In Progress when the first task goes in progress, and the automatic transition of stories from In Progress->In Review when the last story is done. But this annoying prompt is confusing our team members and fighting our agreed upon practice.

I would vote for it.

Really want this change!!! It's annoying as hell because I have two "completed" statuses, neither of which are appropriate for just after completing the subtasks. There are statuses that the issue needs to go through before moving to a completed status! Agile shouldn't assume the issue has completed it's workflow when the subtasks are completed!

Many thanks for reporting this issue, however this is not something we plan to add to JIRA Agile at this time.

Regards,
JIRA Agile Team

I think this is an important change. The feature should not be set to done when a team member finishes the last task, that should be up to the product owner.
In fact, i think this should work in the opposite direction. When the product owner identifies a feature as done, and sub tasks should be transitioned to match the parent.