I don’t understand how to get nested task relationships (hierarchy)

[Alex]

Hello!

Please help me figure it out, I've been struggling with this problem for a week now.

I'm trying to come up with an algorithm so that I can add values ​​from a trigger task to the entire chain of related tasks.

My germ of code that I ended up with (I'm using the script console - scriptrunner):

import  com.atlassian.jira.issue.link.IssueLink ; 
import  com.atlassian.jira.comComponent.ComponentAccessor ; 

List issuesFromEpic = [] 

def  Issue = Issues .getByKey( 'PROJECT-4198' ) //issue trigger

IssueEpicLinkName = ComponentAccessor .getIssueLinkManager().getOutwardLinks(issue.getId())findAll { 

it.issueLinkType.outward == "blocked"   

}*.destinationObject 

IssueFromEpic += Issue 

IssuesFromEpic += "blocked ->" + IssueEpicLinkName 

return IssueFromEpic 

//output: [PROJECT-4199]

 (PROJECT - 4198 blocked-> [PROJECT-4199])

//output: [PROJECT-4199]

//Next expected result:

//get [PROJECT-4199]]

//[PROJECT - 4199,  blocked ->[PROJECT-4200]]

//get [PROJECT-4200]]

//[PROJECT-4200, blocked ->[PROJECT-4201]]

Total :

List = [PROJECT - 4199, PROJECT-4200,PROJECT-4201]

Thanks for any help. 

Best regards, Alex.

[Alex · Accepted solution]

I made code.

My additional condition is also that there cannot be more than one blocking link "is blocked" in "issue in epic" for the script to work correctly .

Please note this when using the script, it may need to be supplemented to suit your requirements

import com.atlassian.jira.issue.link.IssueLink;
import com.atlassian.jira.component.ComponentAccessor;

List issuesFromEpic = []

String trigger_issue = "PROJECT-2782"

while (trigger_issue != null) {

def issue = Issues.getByKey(trigger_issue)
def issueEpicLinkName = ComponentAccessor.getIssueLinkManager().getOutwardLinks(issue.getId())findAll {
it.issueLinkType.outward == "is blocked" 
}*.destinationObject

if (issueEpicLinkName.size() == 1) {
  issuesFromEpic += issueEpicLinkName[0] 
  trigger_issue = issueEpicLinkName[0]

 } 

else {
  break
}

}

return issuesFromEpic

[Nic Brough -Adaptavist-]

Hi Alex,

I am not quite sure what you are trying to achieve here.  I can see it being a list of issues in a list, but I do not understand how you are trying to work out which ones should be on the list.

Your code looks at issue links and the hierarchy, but these are two totally different things, so I'm a bit lost on which one you want to use to build your chain?

[Alex]

@Nic Brough -Adaptavist- HI!

Input: I have Epic, which has Issues in epic. TRIGGER: When a field is updated in one of the epic tasks, then the script is required to update this field for all epic tasks, with the link type "blocked" , linked with the issue trigger  

[Nic Brough -Adaptavist-]

I can't actually see any use for doing this.

Why is the field not just on the Epic instead of the tasks, as it applies to all of them?

[Alex]

@Nic Brough -Adaptavist- 

Unfortunately, I’m not the one who comes up with the conditions for the problems. Right now I’m just trying to get a hint from the community on how to implement this. Maybe I’m completely confused in loops and am already doing some nonsense in the code out of fatigue. anyway thanks

[Alex]

@Nic Brough -Adaptavist- 

Could you help me ?

Thank you.

Best regards, Alex.

[Nic Brough -Adaptavist-]

I think you should take this back to the people who have defined it.  It is a large amount of work, and when running, could cause you all sorts of performance problems.

What is the benefit of changing a field on one issue and destroying its current content on all the other issues that are grouped with it in the Epic?

What problem would that realistically solve?

(There is a far better alternative, but I still wouldn't implement it until I understood what the problem is)

[Alex]

@Nic Brough -Adaptavist- 

Hi! Thank you for answer!

The field that will be updated is "Target start" and "Target end". It is necessary in order not to edit the field manually, because there can be many tasks in an epic. The goal is to save time when changing deadlines, so that you don’t have to change it manually every time in the task queue

[Nic Brough -Adaptavist-]

Ok, that's going to cause you massive problems because one user might happily change the date, not understanding that they're going to destroy everyone else's dates.  What another person notices the change, they are very likely to put it back, destroying the first person's setting.

Whomever thought up this solution really did not think about it.

then there's a dead simple fix.

• Create four fields.  I'll only describe two of them because it is one pair per Target field
  • Target (epic)
    • Put this field on the Epic issue type only
    • Type: whatever it needs to be - date, number, string, doesn't really matter
• Target
  • Put this field on all the issue types except the Epics
  • Type: Scripted field
  • Output template matching the field type that Target (epic) uses
  • Check that the "searcher" in "edit custom field" also matches the field type of Target (epic)

The script for the field is now (pseudocode to explain, should not be hard to flesh it out)

def myEpic = my parent 

Return myEpic.Target (epic)

You edit the two fields on the Epic, in one place, and all the children of it will show it.  This way there's no confusion and the load is trivial.