SOLVED: Post-Function: Accessing Parent Issue Fields When Creating Subtask

[jhreeves2001]

SUMMARY: I'm attempting to use a Post-Function (executable script in groovy) that will send an email when a subtask is created. The email will contain values from the Parent issue.

CODE SNIPPET: The area of trouble is:

def parentIssue = issue.getParentObject();

//Output statement using "parentIssue.components.size" ---- in tests, I've tried 1, 2, 3, 4 components

ERROR MESSAGE: "javax.script.ScriptException: java.lang.NullPointerException: Cannot get property 'components' on null object"

POST FUNCTION PLACEMENT:

> If I use the groovy script during the COMPLETED transition for a subtask, the code runs great.

> If I use the groovy script during the CREATE transition for a subtask, I get the above-referenced error; regardless of where it is placed in the CREATE transition design:

> Before or After "Creates the issue originally" === error

> Before or After "Re-Index" === error

> Before or After "Fire a Issue Created event" === error

CURRENT SOLUTION: In production, I'm using a series of 24 script listeners to send out emails depending on a certain Parent issue field. The single post function route would allow me to eliminate the 24 script listeners... if I were able to access the Parent Issue with the post function.

COMPLETE CODE (sans import statements):

def componentManager = ComponentManager.getInstance();
def userManager = componentManager.getUserUtil();
def mailServiceManager = componentManager.getMailServerManager();
def mailServer = mailServiceManager.getDefaultSMTPMailServer();
def issueManager = componentManager.getIssueManager();
def customFieldManager = componentManager.getCustomFieldManager();
def parentIssue = issue.getParentObject();
Email email = new Email("tyler@durden.com");
email.setFrom("x@x.com");
email.setFromName("X");
email.setMimeType("text/html");
email.setSubject("X");
email.setBody("-------" + parentIssue.components.size + "--------");
mailServer.send(email);

Thanks so much for your guidance.

[JamieA · Accepted solution]

Hey... I have had similar issues. I think that the subtask link is not present when you get the issue.

You could try reloading the parent issue:

issue = issueManager.getIssueObject(issue.id)

then getting the subtask,

def parentIssue = issue.getParentObject();
assert (parentIssue)

Also I agree with Ramiro, this might not be a problem if done in a listener. But it might... as far as I can tell listeners are really no different from a post-function at the same place as the fire event one.

[Ramiro Pointis]

I'm thinking the same as you, it looks like the link isn't being present yet. That's why I said about the listener, because the link is created by that time I think.

[JamieA]

I don't think it is... seems to be that contrary to popular belief, listeners happen in the same thread as the other post-functions, so it's not present when the "fire event" function happens, it won't be in the listener. Could be wrong though. I think reloading the issue may help.

[jhreeves2001]

Jamie, thank you so much for your insights on this! I'm going to work your approach into this now. Be back with a response in 15 minutes, tops. An initial attempt gave me some errors in the script listener approach --- I'm making some simple error / oversight ("unable to resolve class CustomFieldManager, Email, and IssueManager).

[JamieA]

I'd hold off on the listener, just try reloading the issue in your current post-function... the code is in my answer.

[jhreeves2001]

Hi Jamie,

I added the following code to the post function:

issue = issueManager.getIssueObject(issue.id);

def parentIssue = issue.getParentObject();

... and I received the same null message "Cannot get property 'components' on null object."

Please forgive me for asking the following questions:

>>> Should I be using the "assert(parentIssue)" , or is this simply to test if the parentIssue is not null?

>>> I have not used a "def" issue statement anywhere. Do I need to use "def issue = issueManager.getIssueObject(issue.id)"?

Thanks again for your guidance, your help is really appreciated.

[jhreeves2001]

Sorry -- I inserted the assert statement and received an "Assertion failed: assert(parentIssue) null" in the log file.

I'm stuck.

[JamieA]

The assertion is just so it fails early with a simple message. I'm not sure we have the same problem. I just wrote a simple script that I put as the first post-function on the Create step. It worked fine for me:

log.debug issue.getParentObject().getComponentObjects()

Note - you would expect that to fail if this workflow also applies to the parent types, if so you need to check whether it's a subtask or not. Can you try with my simple script... change to log.warn or adjust your debug levels.

Off to watch some football, will check back in tomorrow.

[JamieA]

You are actually modifying the sub-task workflow right, if using different workflows for the parent type?

[jhreeves2001]

Hi Jamie, Your question solved my issue --- I'm attempting to understand where my logic is wrong.

Your question ---> "You are actually modifying the sub-task workflow right, if using different workflows for the parent type?"

Instead of using the getParentObject, per your guidance, I accessed the components via the issue object. The following code worked, but I'm not sure why it did work:

email.setBody(">>> " + issue.getIssueTypeObject.isSubTask() + ">>> " + issue.components.size + ">>> " + issue.getCustomFieldValue(customFieldManager.getCustomFieldObjectByName("FavoriteFutballTeam")));

Output = >>> TRUE >>> 3 >>> Real Madrid

Question: Why did the issue.getIssueTypeObject.isSubTask() return true if issue is referring to the parent object, not the subtask? The parent issue has 3 components selected and a custom field named FavoriteFutballTeam. The subtask does not have a components field or a custom field named FavoriteFutballTeam.

If issue is the parent, I would think the isSubTask would return FALSE.

WORKFLOW BACKGROUND:

My parent issue has a different workflow than my subtask issue.

My postfunction is contained within the CREATE transition of the subtask workflow.

In summary --- you've solved my dilema --- for which I'm very grateful. I'm confused about the isSubTask boolean equating to TRUE, when the issue object is giving me direct link to the parent level fields.

Thanks Jamie!

PS: I hope by football you mean the UEFA Champions League Semifinal 2nd leg? The beautiful game; definitely!

[JamieA]

Hi Tyler... yes, I was meaning the Chelski. And who would have thought that £50m Torres would ever score again.

I have to admit, I'm very confused by what you have above... to be honest, normally I'd guess this was pilot error, ie you've somehow put the parent workflow on the subtask or something, but you seem to have checked that.

I have seen occassions where issue.getIssueTypeObject.isSubTask is true, yet issue.parentObject is null, and that's when the script code is running somewhere in the middle of the creation process, ie the subtask issue has been created, but the subtask link (which is a specialised type of the normal issue link) has not been created yet. But I don't think that's your problem either.

How is the subtask getting created... is a user doing it, or is happening programatically (and if so, how?)?

cheers, jamie

[jhreeves2001]

Thanks Jamie ---- thanks for this question, also >>>> the subtask is created via ScriptListener. The algorithm for the ScriptListener is === CreateSubtask Listener === when parent issue workflow is set to X, then autocreate a subtask called X.

One can only imagine how Torres felt (scoring in Nou Camp == home country, against many of his national teammates) after his well-covered scoring drought.

Chelsea's victory in reaching the Finals seems to have taken a toll on their chances --- four big names currently out (Terry, Ramires, Ivanovic, and Meireles). Big one today. It's hard to imagine a bigger story than Jose facing off against his old employer in the Finals ---- but I'm getting ahead of myself --- we've got 90 minutes to play today.

[JamieA]

;-)

OK, so if you're using the built-in script for creating a subtask, that copies all components from the parent, so chances are you don't need to get the parent object for the subtasks anyway.

[jhreeves2001]

Cool, thanks Jamie. I've converted all of my parentIssue objects to issue objects and it's all running great except for one item: Issue Type.

When using "issue" I'm able to access all the parent issue fields except one >>>> Issue Type

Issue Type for Parent = X

Issue Type for SubTask = Y

issue.getIssueTypeObject.getName()

returns "Y"

issue.getKey()

returns the Key for the Subtask. Is there any way to access the parent as a separate issue by supplying the subtask key???

Is there any way to access the value X (parent Issue Type)? For all fields, except Issue Type, I'm pulling the parent. For Issue Type, I'm pulling the subtask.

Thanks so much, Tyler

[JamieA]

> Is there any way to access the value X (parent Issue Type)? For all fields, except Issue Type, I'm pulling the parent. For Issue Type, I'm pulling the subtask

I think you're getting the subtask, if this script is running in the context of a subtask workflow function... it's just that all fields will be duplicated to the subtask. The way to do it is issue.parentObject.issueTypeObject.name, but then we're back to square 1, because that was null for you (inexplicably, because it works for me).

[Ramiro Pointis]

I'm asking just in case. Have you tried to add this code in a Script Listener that it is executed with the event 'Created issue'?

I mean, since it is not wotking like a post-function, this could be a listener that is executed using an event from the Post-Function. Just an idea.

[jhreeves2001]

Hi Ramiro,

Thanks for your quick reply and idea.

I had not considered this as a solution.

Currently, I have a script listener that creates the subtask (called subtask X). If I edit the script listener for this subtak creation, there is a field called "Additional Issue Actions."

Are you asserting that I may be able to create / send emails via this "Additional Issue Actions" field?

I'll give this a shot; thanks again, Tyler.

If anyone has any other ideas, please, please, I'm open to other ideas as well and will continue working on Ramiro's solution.

[JamieA]

No, use a custom listener as documented here: https://studio.plugins.atlassian.com/wiki/display/GRV/Listeners. But I'd try my suggestion first.

[Ramiro Pointis]

Maybe you will be able to do that, but only trying or @Jamie would know this right now. If not, you could create a new Script Listener that is fired after this one. BTW, the solution given by @Jamie looks pretty good. I almost sure that it will work better than mine.

[jhreeves2001]

HI Ramiro, thanks so much for your guidance.

[Fabrizio Galletti]

Does it works for jira 4.4.4 too?

When i create an issue i woldu like to create a subtask with some field copyed from the parent issue.

I don't want a 1on1 match fot these fields, but for example copy the "parent myfield1" to "subtask myfield2"

[jhreeves2001]

Thanks for all of your help over the last couple of days, Jamie. This is great stuff.

[jhreeves2001]

Hi Jamie,

I hope by football you mean the UEFA Champions League Semifinal 2nd leg? The beautiful game; definitely!

Please give me a couple of hours to look into your additional guidance. Hopefully, I can be done before Madrid hosts Byern Munich. It's going to be a great one, for sure.