Cascade in JPD by using a helper value field & child parent link automation

[Yannic Wolf]

Hi There, 

We are using JPD in our department

I am aware that as of now there is no easy way of cascading ideas under each other within a view. However, I am exploring a way that by using a custom helper value field to possibly achieve this. 

I have 2 fields: 

Custom select field: Top level Idea, Child level idea

Custom number field 'Helper value': 

The automation that I am trying to make is I think relatively simple but I am failing for the automation to do something and that could just be due to my limited programming knowledge. 

In my mind, a solution could be looking somewhere like this. The number you see is the helper value. So by sorting low to high on helper value you can make them be below their parent. 

In our business Top level ideas are only committed each quarter whereas child ideas are more frequently committed to. Even though this solution requires us to ensure that the parents helper value are in iterative order. We only commit to a few (10-15 ideas each quarter) so manually ensuring there is only one full number for each parent idea isn't much of a lift. 

The automation that I am attempting to do is basically:

Whenever an idea is linked to a parent then copy the helper value of the parent and fill in the child helper value with parent helper value + 0.1 

here the audit log: 

I am always getting the 'no related issues be found' and therefore the edit is not happening and I don't fully understand why. 

I am sure that it's just something missing 

[Yannic Wolf · Accepted solution]

Thanks @Bill Sheboy 

I did what you suggested and doing a step by step and that helped thank you!

Now I am running into a problem that the helper value field is not taking the parent helper value field and adds 0.1 to it. It only adds the 0.1 

I've tried several variations of the edit issue: 

{{issue.parent.customfield_15767}}+ 0.1

{{issue.child.customfield_15767}}+ 0.1

{{issueLink.fields["Helper Value"]}} + 0.1

 One example that only changes the value to 0.1: 

I've also attempted the copy issue splitting it into two edit issues. 

1. to copy from the parent helper value field

2. add 0.1 to the custom field Helper value. 

All no dice. It does add the 0.1 to the child issue but does not get the 1 from the parent

For Clarification, the direction I am testing is from the child issue adding 'is child to' 

[Bill Sheboy]

When trying to use the "parent" data to update the trigger issue, the branch cannot be used as you show.  Instead, use the Lookup Issues action with JQL to get the parent issue, and then use that to update the trigger issue.

Next, your math expression is not using a correct format: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/

For example...assuming the parent is stored in the lookup results with only one issue, to add the 0.1 value to the field please use this expression:

{{#=}} {{lookupIssues.first.yourField}} + 0.1 {{/}}

If you are trying to sum to a different issue, please let me know.

[Yannic Wolf]

I am so sorry @Bill Sheboy  you are already helping me so much, and I still run into problems. 

So I've attempted a look up issue like you suggested 

What I am now finding is that, whatever direction I trigger the automation. 

The trigger issue doesn't change. 

I used the log action to help debug.

So let me explain: 

If I am within the child idea linking towards the parent idea the log using {{triggerIssue.key}} tells me the trigger issue is the key of the parent. 

The same happens when I am in the parent idea and link it. For both I get the key of the parent. 

Initially my lookup action was. This gave me an error and after some testing using this with the log it didn't find a parent. 

key = {{triggerIssue.parent.key}} 

After I found out that the trigger issue seems to be always the parent, I changed it to 

key = {{triggerIssue.key}} 

Which then consequently gives me the right key of the parent

But then using your custom formula 

{{#=}} {{lookupIssues.first.customfield_XXXXX}} + 0.1 {{/}}

Edits the trigger issue, which is the parent and not the child. And for this to work I need to the child to be edited. 

And correct me if I am wrong, this would only work if the child idea is seen as the trigger issue? 

[Bill Sheboy]

Hi @Yannic Wolf 

Sorry for the delay in responding as I did not get a notification of your post.

Please post an image of your current complete rule and the audit log details.  I suspect either the edit is in the wrong location in the rule steps or adjustment to the approach is needed.

[Yannic Wolf]

Hi @Bill Sheboy 

No problem 

Here the overall Structure: I've put some log in there to debug which is how I found out that trigger.issue.parent doesn't return anything 

This is the audit log

You can see that the first log doesn't return anything and the second log one does.

In the edit issue I used the formula you suggested to me. 

Ideally I want an automation that works both ways. Link from Child to parent & link from parent to child but I started off with just one direction, then work on the other. 

Many thanks 

Yannic 

[Bill Sheboy]

That audit log does not match the rule shown.  For example, the first write to the audit log tries this and it is not shown in the log:

Parent Issue Key should by 500: {{triggerIssue.parent.key}}

Perhaps save your rule changes, re-test, and then post both the rule and the log images again.  Thanks!

[Yannic Wolf]

No Problem

This is when it successfully fires. but changes the parent not the child value

Added two logs before the actual lookup to debug for the lookup

First log is:  

Parent Issue Key should be 500:{{triggerIssue.parent.key}}

--> this one doesn't return anything

Second log: 

This is what happens when I leave 'parent' out ={{triggerIssue.key}}

--> This one returns the parent 

Consequently, because I want the parent to be looked up, I use 

{{triggerIssue.key}}

in the actual lookup action

This changes the Top level idea helper value to 1.1

---

Now if I copy the automation and change the lookup to the .parent smart value

I get something similar, but it looks up a huge list of issues that are not children.

and this time the helper value in the top level idea changes from 1 to 0.1

[Yannic Wolf]

@Bill Sheboy forgot to tag you ;) 

[Bill Sheboy]

Please pause to consider on which issue this rule is starting, then which smart values should be used, and the differences between "issue links" and issue parent / child relationships using the "parent" field.

Based on the audit log, the rule triggered from CPD-500, and so this audit log write:

Parent Issue Key should be 500:{{triggerIssue.parent.key}}

Will not be 500...It will be the issue that is the parent of CPD-500 (and apparently there is none).

Next, your rule is trying to lookup the same issue as the trigger with:

key = {{triggerIssue.key}}

This is unlikely to be what you wanted.

When you want to use the built-in "parent" field to manage your scenario, the rule should be triggered by a change to that field, and not on issue linking.

[Bill Sheboy]

Hi @Yannic Wolf 

Just following up to check if this answered your question.  If so, please consider marking this one as "answered".  That will help others with a similar need find solutions faster.  If not, please let the community know what help you need with the rule changes.

Thanks!

[Yannic Wolf]

Hi @Bill Sheboy 

I am really sorry I don't think I received a notification when you wrote. 

I ended up redoing the automation and it now works. It's a bit different compared to before but it works like a charm both ways by using a create variable action. 

I've taken the sensitive info out so I can share screenshots so in the actual automation I used the same create variable logic to pull other custom field information from parent to child ideas, so no one has to do the manual task. 

I am now trying to work out using this logic how I can pull the dates from the parent to the child because the edit automation doesn't support date type field, I believe the only way I can do that is by using JSON. 

Either way, thanks so much for all your help! 

Yannic 

[Bill Sheboy]

For a JPD date field, those are JSON stored as text, and so the values may be extracted for use as dates using the jsonStringToObject() function:

{{jsonStringToObject(issue.myJPDDateField).start.toDate}}

[Bill Sheboy]

Hi @Yannic Wolf 

Based on the rule and audit log images you show, the link types do not match.  Links have "direction" and so there can be different link names for the different directions.  For example, "blocks" and "is blocked by".  Have you checked the link types are correct for both the trigger and the branch?

Kind regards,
Bill

[Yannic Wolf]

Hi @Bill Sheboy 

I see. So from what perspective am I looking at this 

The automation that I tested was from Child idea linking to parent 'is child of'. 

Let's say I go into the child idea and link the child as 'is child of' what your are saying the branch Linked issues should be 'is parent of' ? 

Also, that does sounds like I need two branches? 

One if the link is generated from the parents idea to the child and one if he link is from the child to the parent?

[Bill Sheboy]

Short answer: maybe.

For some scenarios, rules using the Issue Linked trigger with no link-types selected will use conditions and branching to handle different link directions.  It always depends on the scenario steps done by the person doing the linking.

• If your rule is triggering as expected with the "Contains" link-type in the trigger, next confirm what link-type should be checked for the branch, as those will be relative to the trigger issue.
• If you rule does not always trigger when expected, I recommend pausing to map out the link-types / directions, and when you expect the rule to run.  That will guide what is needed.