Can Jira automatically reopen a parent ticket if the parent is resolved or closed and a subtask is added or reopened?

[Rob Horan]

We often have subtasks reopened or added to tickets that are resolved.  Generally this doesn't happen on closure.  (though stranger things have happened)  I find it frustrating to see a resolved ticket with open sub tasks.

[William Crighton _CCC_ · Accepted solution]

^{short note to the a-listers having answered this post...clearly I disagree with the approach you all propose - prevention -  on a fundamental level. That being said if you didn't know me, and I don't believe any of you do, it'd be easy for y'all to take my colorful prose herein as a derisive attack on the intelligence and field experience of each author, ultimately signifying a deep and utter lack of respect to your contributions. Nothing could be further from the truth. Apologies in advance if any of this offends}

I've always appreciated the theory behind prevention but never found myself an enthusiastic supporter of anything that stands between me and any place I want to go....much of that, some might say, has to do with particular aspects of my personality often ascribed to patience, compassion and societal norms. Aspects my personality often feel at odds with the rest and wonder just how exactly to leave them behind at the next stop.

Regardless... @Robert Horan, I read through your comments to the different suggestions and thought I'd share my thoughts regarding what I'd implement as a 'solution' to your Q rather than the preservationists (sry, spell checker couldn't handle prevention-ists) message which to me would sound something like "hey stupid, you are asking to do something which only further illuminates the vast chasm of stupidity filled distance between a feeble, small minded approach like yours and 'Our' relative genius - as such, this massive distance between the small thoughts you think and everything we know has us acutely concerned with the quality of 'Our' air such that you'd best trundle off so as to stop wasting ours."

Ok, so that's over the top - but believe you me that's how I'd hear anything said which conveyed the system is working fine, and the fact that I cannot get it to do what I want means you know I'm stupider ....uhh.... more stupid ... whatever. According to the facts I have on the known universe it's not possible to 'see' things from the user's perspective - doesn't mean we can't try. And in this instance what IT might view as user laziness, sneakyness, or process aversion - the user generally sees only as IT weenies abusing the little authority they have. What I always forget about the systems I setup is that the users couldn't give a shit about the systems - at most they kinda care about if the system's working, but mostly they all just want the shit to work enough that they can get what they are responsible for taken care of. As a business owner and an employer I'm faced far too often with this latter behavior. As I think we all are, sometimes. Anyway, great place for a lasting analogy if anyone has one.

I once had a contractor I'd hired help me write some JAVA code supporting an invoicing system I'd designed and implemented - it was my company's first contract. And as we sat and we through the various things I'd coded into my system to work around problems caused by the upstream web developers he exclaimed over and over - as if it were an insult, how I was going around 'wiping the ass' of every one of these upstream developers by not forcing them to fix their broken down crap code. He's like 'That's all you do! You just go around wiping their asses!' - to which I replied 'yea, well, maybe so. but I tell you this - I'm a contractor and there's only one other person in this whole company that's been here longer than me - everyone they've hired comes in and fucks up the code for a few months or year before getting fired or leaving - taking everything they learned or designed while they were here. So yea, maybe I wipe ass for a living - but the system wouldn't work if I didn't do that and anyway, turns out that wiping ass pays pretty damn well."

---

whew...I guess the other posts got me into a sharing mood. It'll pass.

---

Getting back on track here .... and given the mood going further in my answer than I normally would (beings how you asked a yes/no question I would normally answer you with a single word - YES - because JIRA can be configured to do anything within the laws of matter and man. However, given my run up to here a single word just ain't gonna cut it.

You never gave a JIRA version or specified that you were running the server version (instead of Cloud). However, I creeped you a bit and don't think a corp self-described as a leader "in investigations, intelligence and risk management" would be too keen on a cloud solution - So I'm going to assume it's server edition installed...say an earlier version in the 6 series.

Now - once you get the script runner plugin (by Jamie Echlin) installed there's really not much more to do....he has built in workflow post functions that you can just 'use' - I'm thinking the following two would be most helpful for you - to accomplish what you want without writing any scripting.

Certain non-trivial, but non-convoluted workflow changes will be needed. These are the two functions you'll want:

• Fast-track transition an issueHelp
  If the condition is met, automatically transition this issue to another status

• Transition parent when all subtasks are resolved 
  This will do the given action on the parent when all sub-tasks are resolved

You'd need to go into the workflow you project/s are using add a 'fast track' transition option to every state for parent issues. I'd make the transition a universal transition so it has the same name and you only have to configure a single transition, which is what you want if you have a multi-step multi-status workflow.

Then just configure your parent issue workflow's 'fast track' transition to take the parent issue to wherever you think it should be if there are open subtasks. Finally add the post-function to the reopen and create transitions for the workflow and then in your workflow scheme add this modified workflow assigning it to the whatever subtask types you wish to alter the parent issue state. Boom. And that's the hard one.

The 'second part' of your requirement - I'm just saying is a requirement based on my experience when these types of things are asked for - is to automate the closing of the parent issue when all of the subtasks are closed. I mean, come-on, who has time to go and click another button right after they click the other one? I mean...whew! ... seriously though, it makes perfect sense and it is a pita it you don't know the rules cold. For here all you need to do is go into the subtask workflow and add this post-function 'transition parent' for every close transition.

Alrightly! That's a wrap. let's see how many down-votes I get for all ass wiping and other general 'low-brow' language and images toyed with in this illuminating answer.

-wc

[William Crighton _CCC_]

Wait a friggin minute here! Where's the rest of my post! Damn! this thing pisses me off most all the time.

[William Crighton _CCC_]

Thankfully based on long experience I usually work in another page and then post the answer here when I'm done....so: You'd need to go into the workflow you project/s are using add a 'fast track' transition option to every state for parent issues.​ ​I'd make the transition a universal transition so it has the same name and you only have to configure a single transition, which is what you want if you have a multi-step multi-status workflow. Then just configure your parent issue workflow's 'fast track' transition to take the parent issue to wherever you think it should be if there are open subtasks. Finally add the post-function to the reopen and create transitions for the workflow and then in your workflow scheme add this modified workflow assigning it to the whatever subtask types you wish to alter the parent issue state. Boom. And that's the hard one. The 'second part' of your requirement - I'm just saying is a requirement based on my experience when these types of things are asked for - is to automate the closing of the parent issue when all of the subtasks are closed. I mean, come-on, who has time to go and click another​ button right after they click the other one? I mean...whew! ... seriously though, it makes perfect sense and it is a pita it you don't know the rules cold. For here all you need to do is go into the subtask workflow and add this post-function 'transition parent' for every close transition. Alrightly! That's a wrap. let's see how many down-votes I get for all ass wiping and other general 'low-brow' language and images toyed with in this illuminating answer. -wc

[Rob Horan]

Wow, thanks for the time and effort and especially the humor! Sorry for not mentioning it in the description, but we're on Server version 6.0.8 - I plan to upgrade in the relatively near future. You're right on about the cloud and security. It sounds like we'll need script runner. Given the way we are using subtasks, most of the teams using Jira now would not want to automatically close the parent ticket when all subtasks are closed - though I can see where that could be useful.

[Rob Horan]

A part of me wishes we could use the cloud instance of Jira. It would be nice to be able to have the latest version immediately available.

[William Crighton _CCC_]

No script runner in the cloud....makes it a deal killer when the process cannot be modified to adapt to what's available. And the 'niceness' of having the latest version immediately available is a mixed bag as well - it is a truly WONDERFUL thing...until you get calls at 3am from your manufacturing facility in the Philippines because a Cloud update has modified the interface 'too much' for the factory workers to handle (from experience they just totally dislike having things changed underneath them w/o anyone providing formal notice prior to). Those moments, however, pale quite effectively in the face of the late nights some upgrades take. The other thing (among still other great things) that script runner gets you is several sophisticated JQL functions you can use to build more accurate Rapid Board and other filters. And while the plugin is 'free' I strongly recommend cutting the vendor a check for the paltry 400 pounds he suggests per his page. I've started telling my clients they need to buy it lately because (afaik) nobody really does and there'd be no Script Runner w/o Jamie Echlin.

[Robert Dzido]

You can use Workflow PowerBox plugin. It contains post function "Transition related issues" that allows to to reopen parent when one of subtasks is being reopened.

[Rob Horan]

Love it! Except for the part where it costs money and I have a budget between $0 and $0 for plugins.

[Robert Dzido]

sometimes you can save a lot of time by buying something. If you have no budget and your JIRA version support jelly (it's prior to 6.4) you can use jelly script to transition issues. If you combine it with old (last free) version of Craftware Search Linked Issues for JIRA it will work. There ares some cons like: some delay in closing subtasks, and (if your instance is very large) may impact performance a little. Read more here: https://confluence.atlassian.com/display/JIRA063/Jelly+Tags

[Joe Pitt]

I have to go with prevention too. The user's sound like they are trying to take short cuts, which helps them, but may mess up any metrics you try to derive from the data related to number of issues handled, time to resolve, and others. Don't code to their laziness.

[Rob Horan]

This isn't about laziness, it's about a process that is comfortable for all. I'm not going to stand on principle if I don't have any belief in the principle I'm standing on. I want a system that works as it should. Automatically reopen parents under the right circumstances. Our processes will catch the open parents at the right time. Forcing people to take these extra steps is just micromanagement for the sake of saying BWAHAHAHAHAHA SEEEEEE MY POOOOOWAAAAAAA!!

[Nic Brough -Adaptavist-]

If you can install the script-runner addon, then it's not hard to create a listener that can spot new or reopened subtasks and reopen a parent issue.

But I'd go with prevention first, with Jobin's answer

[Rob Horan]

People are going to be very grouchy if I go that route. I would consider script runner if I had the requisite script creation skills :)

[Nic Brough -Adaptavist-]

I know they might get grumpy if they perceive a loss of function, but in this case, I think the benefits probably outweigh the costs. I can imagine that if you implement prevention, a user would come to you and say "I can't create a new subtask, it's broken, fix it, grr". My usual trick here is to paraphrase their requirement back to them to ensure that I understand it correctly. "You would like to create a new subtask on something that has been closed, so you can't report on the parent issue being open while adding new, untracked work to it, and that people are going to be unaware of because the closed item is no longer of any interest, and no-one can justify doing the new work because the parent issue is closed" (and you can probably add more, depending on your processes and lines of responsibility)

[Rob Horan]

Its not just the user's that would be unhappy. I honestly find that solution to be inelegant. Just as I automatically assign a ticket to a user on resolution I would like automatic actions to be taken here. Its smooth. Simple. Thought free.

[Nic Brough -Adaptavist-]

I'm sorry, I wasn't clear - I was pointing out that prevention is easier than making changes on a cost basis only, and in this particular situation. The pragmatic approach for this . Prevention is easier to implement - you can do it with a few conditions and properties and forget about it. Then allow a bit of time for explaining that you've stopped them doing things wrong because it may work for them, but it breaks the processes for other people. The "fix data after someone is allowed to botch it" is also a perfectly valid technical solution in this case. You regain the time from not having to explain why they've been stopped from doing it. But you need to find or write code to do it, and you'll have to write it well, support it, and make sure it still works after every upgrade. The script runner can help you. Oh, and you'll need to be able to explain to the owners of the parent issue who thought it was dealt with why they're suddenly being told that someone has reopened their issue when they're swearing blind they didn't touch it. In *this case* prevention is by far the better method. It's definitely best practice too. (And I still can't help but agree with Joe's comment - "don't code to their laziness")

[Jobin Kuruvilla [Adaptavist]]

"In *this case* prevention is by far the better method. It's definitely best practice too.". That is what I thought too. Honestly, I am a developer and I am all for automatic actions/transitions ;) But in this case, I believe a lot of things can go wrong if someone adds a subtask on a closed task. What if they are adding a subtask on a closed task that was completed in an earlier sprint? How does that affect the scopes, reports etc? How will the assignee of the parent task be notified? What about all the reports/SLAs met? If the user much add a subtask under a closed task, he should be forced to reopen the parent ticket and that makes the user think twice abut what he is doing. And it also notifies the watchers of the parent ticket and they can then take the appropriate action. @William Crighton [CCC] Great answer. Totally explains your stand and one can hardly take offense to that ;) PS: Probably could have implemented the automated transitions by the time I spent on this post!!

[William Crighton _CCC_]

arg....jeez what a pita....just trying to fixup a silly comment makes the...nevermind...sorry for the spam ---- @Jobin Kuruvilla [Go2Group] (sry about that - I always seem to have a hard time with the @ app selections - though for some reason I was able to select you successfully the second time below...idfk) WHEW! True that. had no idea how much time i'd spent till ... it was spent. Thanks for the call out - very cool - when I was done it was hit or miss on whether to delete it or not for just being 'too much'. To answer your question on the affects of adding a subtask with automation to open the parent item - the parent item's participants will be notified when the issue is reopened (assuming intelligent notification scheme). There's a few plugins out there - one we wrote incidentally (Or just use Script Runner) - that allows for adding a comment during a workflow transition which could be leveraged to let the parent issue's participants know what is going on. So I don't think that would be a concern. Your other point about adding a subtask to a story completed in an earlier sprint - I'm not sure about how that would turn out. The story (i.e. parent item) would be reopened via automation and perhaps a comment added stating why (subtask ### was added by <user name> to this issue <issue key> - This has automatically reopened this issue - or something like that). From my experience merging two JIRA Agile Instances using SQL the sprint reports leverage the contents of the changegroup and changeitem table's very heavily. From that same experience I believe - strongly - that since the report generator will determine that the story was closed prior to the sprint being closed it will not adversely affect the report numbers. However, I haven't tested that out - Nice work @Jobin Kuruvilla [Go2Group] , an excellent thing to call out. As far as SLA's met - that's harder to know what the right thing to do is - and definitely something that can be chewed over at a later time. -wc

[Jobin Kuruvilla [Adaptavist]]

You can't do this without customizations.

I would recommend an alternate approach. Use workflow properties to stop users editing the issue or creating subtasks after the issue is closed. They will have to reopen the issue if they want to add a subtask. Will that help?

[Rob Horan]

It will only help me to the therapist when everyone complains about extra work :(

[Rob Horan]

I'm not looking to avoid customization - just trying to figure out what to customize.