Getting the average of multiple custom number fields in the same issue

[Rick Crow]

In Jira Server, I'm attempting to calculate the average of several number fields within the same issue. As a starting point, I've tried using the '+' operator to see if I could simply sum all the values and I can't even get past that hurdle. That attempt looks like within the edit issue action:

{{#=}}{{issue.Evaluation of Exposures}} + {{issue.Renewal/ARR Pricing}} + {{issue.Communication to Agent}} + {{issue.Issue Instructions/Renewal Pricing Sign Off}} + {{issue.Risk Grouping}} + {{issue.Deductible}} + {{issue.Claims Information}}{{/}}

That's returning the following error: Unknown unary operator '{' at position 1:

The other approach I've found googling the topic is to use the appropriate numerical operator, but every example I've found seems to assume there will only be two values involved and I'm unsure if it's possible to use the syntax presented with more than two values.

Any thoughts are greatly appreciated!

[Bill Sheboy · Accepted solution]

Hi @Rick Crow 

I wonder if it is because you have the reserved character / in the names of the custom fields.  Please try to replace the names for those fields with the custom field ID values instead to see if that works.

You may find those IDs from the admin functions or you can quickly just call the REST API with an example issue to see all of them at once.  Here's the how-to for that: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Rick Crow]

Hey, @Bill Sheboy ! Thanks for the suggestion. I just tried that and I'm unfortunately still getting the same error.

I should also mention (I'll update my original question text) that this is within a Server instance. We're in the process of migrating to cloud, so if there's a better solution there, I can shift to solving for that context rather than server.

[Bill Sheboy]

Thanks, Rick.  The next thing to check is if the field types are numeric, as Stefan notes.  If not, try converting each one with asNumber with a default of zero, such as:

{{issue.Evaluation of Exposures.asNumber|0}}

[Rick Crow]

Thanks for the direction. I had assumed these were number fields, but now see they're Deviniti Dynamic Forms select fields. These fields all have the same options:

• N/A
• 1
• 2
• 3

@Bill Sheboy, I've followed your direction and modified the script as indicated. I'm no longer getting an error, but the resulting value is "0" and should be "18" as there are 7 fields with these values: 3, 3, 2, 2, 3, 2, 3.

I've limited the automation to a single issue initially for testing purposes to ensure that no issues in the automation's scope would have a value of 0, or be empty.

As we prepare for migration, these Deviniti fields are being replaced as there is no corollary in the cloud, so if that ends up being a problem, the cloud version of this form will be using either standard number fields or standard select fields.

@Stefan Salzlthere are only two elements to the automation at this point:

• A scheduled trigger using a jql query: issuekey = UWADT-1504:

• An Edit Issue action with my target number field identified as the field to modify with the script in question populating that field:

[Bill Sheboy]

Here is one hypothesis: fields for addons which dynamically generate values cannot be used in smart value expressions other than as a simple read due to the order of operations.

How to test that: write {{issue.Evaluation of Exposures}} to the audit log and see if it has a value.

[Rick Crow]

@Bill Sheboy Thanks for the additional thought. Since I can't use those going forward, I'm moving ahead with the assumption I'll be using either standard select or number fields in the cloud version of this screen. 

I had already created and copied values into the standard version of each of these fields and I've now added those to the screen and modified the script to refer to them rather than the Deviniti fields. While I'm still not getting an error, I'm still getting a response of 0 (zero) in my target field.

[Rick Crow]

@Bill Sheboy Update. For grins, I used your test and wrote both {{issue.Evaluation of Exposures}} and {{issue.Evaluation of Exposures nd}} (the modified, non-dynamic field). As expected, the first one returned significantly more than the field value and the second one returned the value of 3. I then modified the first one to {{issue.Evaluation of Exposures.value}} and it then also returned the correct value of '3'. But neither approach is yielding a correct sum from the automation.

[Rick Crow]

@Bill Sheboy Update: using either {{issue.Evaluation of Exposures.value}} (Deviniti dynamic selects) or {{issue.Evaluation of Exposures nd.value}} (standard select fields), I'm now getting a valid sum.

Finally then, I've modified the script to divide that sum and I'm now good!

{{#=}}({{issue.Evaluation of Exposures nd.value}} + {{issue.Renewal/ARR Pricing nd.value}} + {{issue.Communication to Agent nd.value}} + {{issue.Issue Instructions/Renewal Pricing Sign Off nd.value}} + {{issue.Risk Grouping nd.value}} + {{issue.Deductible nd.value}} + {{issue.Claims Information nd.value}}) / 7 {{/}}

Thanks for helping point me in the right direction.

[Bill Sheboy]

I am glad to learn that worked.

Often the trick in getting an automation rule to work is using the correct smart values (name, capitalization, spacing, etc.)  This how-to article may help find all of the available smart values, and their respective custom IDs, for an issue: 

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Stefan Salzl]

Hi @Rick Crow ,

Could you maybe provide a screenshot of the automation rule? that would give us the possibility to see the whole scope/context and eventual other settings that might affect the rule.

Furthermore:

- Could you please re-check and confirm that all the required fields are of type number?

- Is it granted that ALL fields are filled with value? Otherwise I would suggest to use defaulz value 0 in case of an empty field because an empty field would break the calculation (as far as I know).

Best
Stefan