{{lookupIssues.Story Points.sum}} not working for me.

[gordon.varney]

The goal is to: when a story, already attached to an Epic, has it's Story Points changed, that triggers automation to, from the triggering story, to looking at the associated Epic, find all the issue under that Epic, add up their individual Story Points, put that number in the Epic's Story Point field, drop a note in the Comments field, and be done.

There is quite a collection of asks and answers around this for regular fields, custom fields, adding up specific fields, whatever. I just can't get this to work. All the peripheral stuff does: I can write to the Labels field, I can write to the Comments field.

If I manually put some number in the Epic's Story Point field before triggering the automation, when the automation runs, it always overwrite the existing number with 0.

What am I doing wrong?

Cheers.

JGV

Overall Automation

Detail on the Story Points Calc

Pre-Changing a Story's Points

Post-Changing a Story's Points

[Trudy Claspill]

Hello @gordon.varney 

My suspicion is that the problem is your Lookup Issues JQL statement:

parent={{triggerIssue.parent.key|"null"}}

Why did you add |"null" ?

You might want to add a Log action after that to confirm that your Lookup Issues action is actually returning issues. You can log the smart value {{lookupIssues.size}} to see how many issues were found.

I would suggest putting the Lookup Issues action within the For Parent branch and use the JQL:

parent={{issue.key}}

There is no reason to execute the Lookup if the trigger issue doesn't have a parent. If the trigger issue doesn't have a parent, then the For Parent branch will not be executed.

[Bill Sheboy]

Hi @gordon.varney 

Adding to Trudy's suggestions:

Your rule has multiple Edit Issue actions.  Those changes potentially walk-over / collide with earlier saved data as actions use the current state of the issue in the rule's storage for the edit (and not what is stored in the cloud).  This is intentional and is not a defect in the rule engine.

Why are you editing the issue multiple times rather than one time, selecting and updating the different fields needed?

When you need to edit an issue in a rule and have those results available for later steps, add the Re-fetch Issue action after the edit to reload the data.  However this is likely not needed for the rule you show.

Kind regards,
Bill

[Trudy Claspill]

Hello @gordon.varney 

Referencing your latest rule version:

I would not expect this version to get you the result that you want.

For one thing in the last log message {{issues... is not a valid smart value. It would require that issues be a reference to a list of issues, but you have not taken any action to get a list of issues.

Here is the gist of the change I suggested - moving the Lookup Issues action inside the branch. I'm just using Log actions, not actually editing anything.

1. When the Story Points field is changed

2. Shift focus to the trigger issue's Parent. If the trigger issue has no Parent, then the rule doesn't execute any portion of this branch.

3. Search for the child issues of the Parent. At this point in the rule {{issue}} refers to the Parent of the trigger issue, so {{issue.key}} is the key for the Parent of the trigger issue.

4. Here we are printing the count of issues found. In this case it should be at least one because otherwise this branch would not be executing.

5. Print the sum of the Story Points fields for the issues found by the Lookup Issues action.

Some refinements that can be made:

Lookup only the child issues that actually have a Story Points value. With this refinement the results set could possibly be no issues. 

If the result set might be zero, then we add |0 to the sum statement. That tells Jira that if the sum function doesn't produce a value, use 0 as the value.

[Bill Sheboy]

Yes, and...

The plural {{issues}} smart value is only supported for Jira Data Center's bulk-handling feature, not for Jira Cloud automation.  (Although experimentation I did years ago showed it does return unpredictable "stuff" when used in a Cloud rule :^)

[gordon.varney]

Good morning. So, changed to your example Trudy. Using "issueS". Writes to log produced the static text but not the variable.

And just for kicks and giggles, I tried "issuE" - no S. same result.

So, am it totally then barking up the wrong tree? This is NOT going to work?

Cheers.

JGV

[Trudy Claspill]

Please post a new image of your rule.

What exactly are you referencing in my example? I don't believe anywhere in my example have I used a reference to issues with a capital "s" at the end. But maybe I'm not seeing it because I have looked at it multiple times.

Smart values are often case and space sensitive. With the lookupIssues portion of the smart value all letters need to be lower case except for the "i"

[gordon.varney]

Over all automation

First condition, trigger

Second condition, in branch

Third condition

Fourth condition

Fifth condition,

Results

[Trudy Claspill]

Thank you for that additional information. 

The lookupIssues smart value does need an "s" at the end; plural lookupIssues rather than singular lookupIssue.

[gordon.varney]

Well, getting there.

Changed lookupIssue to be lookupIssues and it now counts the number of issues.

It calculated just fine = 3.

It returned the sum as zero.

Tried playing with that  every way I could think of.

First lookupIssues item this now works.

This is how the second lookupIssues looks. And it returns 0.

And results in the log...

[Trudy Claspill]

The log should include the keys for the trigger issue and the issues found by the Lookup Issues action. Have you reviewed the child issues to confirm that at the time this rule ran those issues had non-zero values in their Story Points fields?

An additional condition you may want to add as the first component within the branch is a Field Value condition to confirm that the parent issue is Issue Type equals Epic.

As the rule is currently written, technically the rule could run for other combinations of parent and child issues; i.e. Task and Sub-task, parent of Epic and Epic.

[gordon.varney]

[gordon.varney]

Will add that additional condition now.

[gordon.varney]

I just don't get it?????

[Trudy Claspill]

Hm. The look of your Audit Log interface is different from mine. I wonder why.

Some times a rule that has been edited may times may start behaving in an unexpected manner. Can you disable this rule, and then try recreating it again from scratch? Don't copy anything - start with creating a brand new, empty rule and add each component again.

I have created the same rule (without the condition to confirm the parent is an Epic) and it works correctly.

Another thing that I tried was adding a Log action to log the issue key and Story Points value of each child issue.

 

In this case 3 of the 6 issues really do have no value for Story Points.

[gordon.varney]

Trudy, thank you so much for hanging in there with me. I tried reproducing some of what you did above, with these results. And I did type the whole thing in again.

JIRA can take the path from a Story's points changing, to the Stories Parent, to counting how many issues are under the Epic just fine. It can even give us the numbers of those three issues. It just won't read their story points.

Hmmmmm. Going to try writing, hard coded, the first issues story points and see if we can see that.

[gordon.varney]

So, played some more. My JIRA is not seeing the story points field. Seemingly on anything. Just noted, there are two smart values for Story Points. Am I using the wrong one? Everything I see on our instance says Company-managed.

[Bill Sheboy]

Hi @gordon.varney 

Out of the box, Jira unfortunately has two fields depending upon the project type:

• Company-managed projects use the "Story points" field, with a smart value of {{issue.Story points}}
• Team-managed projects use the "Story point estimate" field, with a smart value of {{issue.Story point estimate}}

If you see another "Story points" field in your global configuration (i.e., for company-managed projects) then someone added another one, and that is causing problems.

To quickly solve this, please identify the custom field ID for the correct field and use that: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Then research why an additional field was added and resolve that problem to reduce future problems.

Kind regards,
Bill

[Trudy Claspill]

That is precisely what I was going to advise as the next step!!

[gordon.varney]

Removed.