Suggestions to rewrite complicated Postfunction from Jira Workflow Toolbox

[Mathew Lederman]

We have the below script currently used in the JWT plug-in that we need to change to a postfunction in Groovy, ScriptRunner or Project Automation. Any suggestions are appreciated:

Create issue link based on the following parameters:

Issues returned by JQL query “issueFunction in linkedIssuesOfRecursive("issueKey =%{Issue key}") and issuetype="PS Change Request"” will be linked with issue link type is part of to every issue returned by JQL query issueFunction in linkedIssueOf("issueKey=%{Issue key}", "is part of").

[John Price]

You're right, it's a bit complicated.  Can you explain in plain language what exactly you want to accomplish?  It looks like you want to do some soft of bulk linking of issues to one another, right?

[Matt Doar _Adaptavist_]

Be careful about using the Recursive function, since that might take a while to run in larger cases

[Mathew Lederman]

@John Price that's where it gets even more complicated. I'm the Jira admin for our instance looking to change post-functions from plug-ins that don't migrate to the Cloud to plug-ins that will migrate. This postfunction is from the Jira Workflow Toolbox and while JWT does migrate, this function does not.

I've asked the team for an explanation of their goal and unfortunately even they can't communicate clearly as this post-function links issues between projects. It was setup years ago and the people who configured it are no longer with the company.

To the best of my understanding this is what it's doing:

Issues returned by JQL query “issueFunction in linkedIssuesOfRecursive("issueKey =%{Issue key}") and issuetype="PS Change Request"”

For a given issue (A-1) find all of the issues linked to A-1. For this example we'll say the issues linked to A-1 are A-2 and B-1 . Then find the issues linked to A-2 and B-1 where the issueType = "PS Change Request"

This will return a list of issues such as B-2, A-3, and B-4.

issueFunction in linkedIssueOf("issueKey=%{Issue key}", "is part of").

This will return all linked issues to A-1 with a link type of "is part of". For this example we get A-4, and B-5

will be linked with issue link type is part of to every issue returned by JQL query

Finally, it links B-2, A-3, B-4 with A-4 and B-5 with an issue link type of "is part of"

[John Price]

Hi Matt -

Sorry for the late reply.  I feel your pain, as I have run multiple migrations to Cloud and many of those had JWT/Groovy/etc. functions whose creators are long gone.

I realize this isn't really answering your question, but my recommendation would be:

• Let the affected team know that you can't migrate this function, and ask them what the impact would be.
• Let them know you're happy to help, but you need someone who can at least demonstrate how the links are used - a dashboard?  Reports? 
• If that fails, ask them to try living without the function on day one, and give them a clear path to some consulting with you later if needed.
  
  

I'm going to hazard a guess and say the scenario is something like:

• They have a "dev" project where they track product work, including bug fixes.
• They have a different "support" or suggestions project where they track change requests and reported problems.
• When they release a product update, they need to know which customer requests and problems are resolved by the update so they can tell users and customers.
• The dev project is using a hierarchy like Epic/Story, Epic/Bug, etc. 

If that's the case, there are better ways to solve this. For example, a good support team should always search for known dev issues and link them to the customer requests.  Likewise, the product owner should have a handle on what's being solved in releases. If those people are creating the links as they go, then you could use fixVersion to find and update things rather than worrying about the hierarchy.