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.
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:
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?
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
It will only help me to the therapist when everyone complains about extra work
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
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.
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)
Wait a friggin minute here! Where's the rest of my post! Damn! this thing pisses me off most all the time.
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
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.
I'm not looking to avoid customization - just trying to figure out what to customize.
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.
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.
Love it! Except for the part where it costs money and I have a budget between $0 and $0 for plugins.
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
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!!
It looks like you're new here. Sign in or register to get started.
![Photo of Jobin Kuruvilla [Adaptavist]](https://us.v-cdn.net/6038660/uploads/avatars/17/c4/n17c4b8c7de7da6cee02bd69e8a3b017b.png)
