How to sum story custom filed values to an epic?

[Rita Arellano]

Hi All, 

I have found a very good resource that provides step by step detail on how to roll-up story points to an epic here is the link: 

https://support.atlassian.com/automation/kb/rule-to-sum-up-the-story-points-from-stories-to-a-linked-epic/ 

However, this does not work well when you are trying to roll-up from a story's custom field values to an epic. 

This is what I am trying to accomplish:

1. Stories have a custom numerical field called 'LOE'

2. Trying to add all the story's  LOE field values. 

3. The story LOEs should roll-up to the epic's LOE field to display the total LOEs for all the linked stories. 

Here is my automation. It yields no results as the LOE field for the epic always stays at 0, but somehow my audit log shows success:

[Bill Sheboy]

Hi @Rita Arellano 

Short answer: That knowledge base article will not work for your field.  Instead you may use the Send Web Request action to call the REST API with an issue search to sum the field.

More information...

Only a few fields are currently supported by the Lookup Issue action for that version.  Here are the supported fields: https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html#Jirasmartvaluesissues-lookupissues-properties

And here is the suggestion to add the other fields: https://jira.atlassian.com/browse/JIRAAUTOSERVER-877

For your scenario of updating the parent Epic, a workaround would use the REST API rather than the Lookup Issues action, and then sum the fields in the {{webhookResponse}}

• trigger: value changes for LOE
• condition: issue type equals Story
• branch: to parent issue
  • action: Send Web Request, to call an issue search with the JQL you would have used for the lookup
  • advanced compare condition: check the call was successful by checking {{webhookResponse.status}} equals 200
  • action: edit issue, setting the field to the sum of your field.  It might be this:

{{webhookResponse.body.issues.fields.LOE.sum|0}}

To help implement that...

Here is a how-to article for calling the REST API from a rule: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

I believe this is the REST API endpoint you need: https://docs.atlassian.com/software/jira/docs/api/REST/9.13.0/#api/2/search-search

Finally, you may need to use the custom field id rather than the field name LOE.  This how to article will help identify that value for your field: https://confluence.atlassian.com/automation/find-the-smart-value-for-a-field-993924665.html

Kind regards,
Bill

[Christian Freimüller]

Thanks, @Bill Sheboy for your explanations! This saved some headache for me...

Maybe an additional information, as long as IRAAUTOSERVER-877 has not been implemented:

If your administrators have renamed the "Story Points" field to something else - e.g. "Estimate", you also cannot access the story points estimates via Lookup Issue action via the Smart Value {{lookupIssues.Estimate}} - and therefore also no numerical operations like "SUM" work. Accessible fields on lookupIssues seems to be to some extend "hard-coded" for some reasons...

Only when the admins rename the field back to "Story Points" the Smart Value + numerical operations started working again as described in the documentation linked above: {{lookupIssues.Story Points.sum}}

[Bill Sheboy]

Yes, and...

In general I would not recommend renaming built-in fields.  We do not know how the code accesses them in all locations (i.e., by name or by id), and so results may be unpredictable. 

When a differently named field is needed, creating a custom field may be better...accepting some built-in functions may not automagically work with that custom field.  For example, creating a different relative-sizing field than Story Points.

[Rita Arellano]

@Bill Sheboy Thanks for all the details. I am learning on how to implement these steps. I am a bit confused about this step you suggested above:

"branch: to parent issue

• action: Send Web Request, to call an issue search with the JQL you would have used for the lookup."
  
  

This is the JQL I used for the lookup, but I get the below error - can you please offer any guidance on how I can successfully add the ((value.urlEncode}}?

[Bill Sheboy]

Your JQL to find the issue with the lookup was:

"Epic Link"={{issue.key}}

And that would be passed as a parameter in the URL:

your Jira URL/rest/api/3/search?jql="Epic Link"={{issue.key}}

Please review the how-to article to learn more about calling a REST API endpoint from a rule.

And...please select the option at the bottom of the Send Web Request action:

Delay execution of subsequent rule actions until we've received a response from this webhook.

This will pause processing until the call returns, letting you check the results and response message.

[Rita Arellano]

@Bill Sheboy Thanks, for the above I had to use cf[10101] instead of "Epic Link": 

 https://confluence.atlassian.com/jirakb/retrieve-user-stories-added-to-epic-using-rest-api-jql-search-779158635.html 

your Jira URL/rest/api/3/search?jql="cf[10101]"={{issue.key}}

 
I have followed all the steps, but I see I am getting a error of : HTTP status 401. Could you see if I have missed something? otherwise, I will take it as I just don't have the access. 

[Christian Freimüller]

Dear @Rita Arellano ,

in general - for better debugging purpose, please make use of the "Log Action" action whenever needed. It really helps during rule creation.

-> in this case log as suggested in the Webhook action e.g. {{webhooResponse}} or {{webhooResponse.status}}

In general http status code 401 means "Unauthorized" -> wrong credentials.

I assume your company is using Jira Data Center - please check which version in the "About" menu on the top right.

Then consult this page to point to the right REST API documentation and which authentication methods are supported. In my case I couldn't use the PAT, because my company is still on version 9.12.x of Jira -> only OAuth 1.0a and Basic Auth (username/password) are available to me.

Once you know which authentication mechanism is available and fits your purpose, you have to encode it base64 as described here or here.

Cheers, Christian

[Bill Sheboy]

Hi @Rita Arellano 

Christian is correct as I suspect you have not encoded the API token.  Please see the linked articles we both provided.

Regarding the REST API call, there is no need to pass Custom Data as everything is on the URL for the call. So change the Webhook Body option to Empty as that JSON is not needed.

[Rita Arellano]

@Christian Freimülller @Bill Sheboy 

Hi There, 

I have Jira DC 9.12. I am told we could do the Basic Auth, but I keep getting 401 errors. I am sure that I am encoding my API token as I am going through this terminal to do so Base64 encode 

I am using this very same format, then running it through here Base64 encode 

$ echo -n "My_Email@Domain.com:My_Token" | base64

I am starting to suspect, maybe I just don't have the access since I am not a global admin. Since, the only errors I am getting are 401.

 

[Christian Freimüller]

hmm... different thing I might have spotted.

In @Bill Sheboy initial reply he point to v2 API version of the search interface.

I also could find only v2 for Jira DC 9.12.x - see The Jira Data Center REST API - Get api 2 search.

Version 3 is afaik only availble as Beta for Jira Cloud - see The Jira Cloud platform REST API (atlassian.com) - Issue search

BR, Christian

[Dan -minware-]

Disclaimer: 3rd party marketplace partner!

Hey @Rita Arellano - if you are open to working with a 3rd party this is very easy for us to do in minware. 

We offer a free trial so please reach out if the other solutions proposed in this thread do not meet your requirements and you want to check it out.

Cheers,

[Trudy Claspill]

Hello @Rita Arellano 

The smart value you are using is incorrect. Try {{lookupIssue.LOE.sum}}

It still may not work because the sum function does not necessarily work on all custom fields. But the syntax will at least be correct.

If a rule can't evaluate a smart value the rule will just consider it to have no value. It will not cause the rule to report an error