nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Use smart value for child sub-task

Lukas_jh1ro7

As you can see I have here 3 custom fields "Residual risk impact", "Residual risk likelihood" and "Management approval necessary?" in the parent task. All 3 fields are at some transition screen and if the user choose at third custom field "Management approval necessary?" the answer YES, it should be a subtask created with another 2 custom fields, namely "Residual risk score" and "Residual risk level". Those 2 fields shoud be copied from parent task after creation of the subtask.

risk treatment1.PNG

Residual risk score will be calculated from the first 2 custom fields, for example if Impact is 3 and Likelihood is 4 then Risk score will be 3x4=12. If I fill the all necessary fields on trasition screen, the subtask immediately got created, however the Risk score and Risk level fields in the subtask are blank, which should be copied from parent task, because for the risk score calculation you need maybe 1 or 2 seconds. So that means Risk score and risk level is calculated onparent task, however at the time, where the subtask get created, the fields re still blank.

Here is the screenshot from the subtask with blank fields:

risk treatment 2.PNG

But as I wrote, on the parent task, you see, how this fields are calculated after one or two seconds:

risk treatment 3.PNG

So my question is, is there any way "to wait" for one, two seconds with the creation of subtasks, until the custom fields, which I need, are all get calculated?

Accepted answers

Bill Sheboy

Hi @Lukas

Without seeing the specifics of your rules, my suggested answer is: maybe.

Let's assume you have two rules:

one is calculating the Residual Risk Score, and
another is triggered on a change to Management Approval Necessary, to then create the subtask

If you do actually have rule #1 to calculate the score, perhaps change the trigger of rule #2 to detect a change to the score (and turn on "Allow Rule Trigger" in the rule), and add a condition for Management Approval Necessary before creating the subtask.

Another approach would be to add a Re-fetch action at the start of rule 2, slowing the rule slightly to allow the calculation of the score to finish. This is probably unreliable due to racetrack/processing performance issues.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Lukas

Without seeing the specifics of your rules, my suggested answer is: maybe.

Let's assume you have two rules:

one is calculating the Residual Risk Score, and
another is triggered on a change to Management Approval Necessary, to then create the subtask

Kind regards,
Bill

Lukas_jh1ro7

@Bill SheboyI combined both of your approaches, and it seems, it works fine. Thank you! However the meaning of re-fetch function is still foggy for me.

Bill Sheboy

Awesome; I am glad to learn that worked.

Short version on Re-fetch: it reloads the data for the trigger issue at some point in a rule.

Longer version:

Regarding the Re-fetch action, the primary use is when an issue's data changes in a rule, and you need to use the changed values later in the same rule. For example in this rule:

trigger: some trigger, such as manual
action: edit issue, changing the description field
action: send email, containing the description field

In this rule, we are editing the Description field and then using it later to send an email. The edit updates the Description in the cloud, but the rule still only has the original value from when the rule triggered. So our email will be wrong. This is not a defect, per se...it is how rules work; sometimes we really do want the fields to remain unchanged until the end of the rule.

To fix this behavior, we add a Re-fetch action after the edit and before we reference the Description, which pause the processing to re-load the trigger issue from the cloud.

trigger: some trigger, such as manual
action: edit issue, changing the description field
action: re-fetch
action: send email, containing the updated description

Now, our email will correctly contain the updated value.

However there is another use (i.e. hack): fix when a rule triggers too quickly, particularly for the Create Issue trigger. The rule starts running before the new issue's data is available enough in the cloud for the rule to access it.

So when the rule runs it sees many of the fields as empty! For field use or conditions in the rule, they may not work as expected. This problem is known as a racetrack error, where one thing outruns another in processing.

The fix/hack is to add a Re-fetch action immediately after the trigger. This will slow down the rule and reload the data. Hopefully this provides enough time for storing/loading the cloud data. This usually works, but not in all usage scenarios. Also note the Re-fetch adds a second or more to the processing time for a rule.

Lukas_jh1ro7

@Bill Sheboythank you for the good explanation! I have now a some strange problem with my smart value/ custom field "Residual risk level". Basically I use very simple math calculation for "Residual risk score": {{#=}}{{issue.Residual risk impact.value.right(1)}} * {{issue.Residual risk likelihood.value.right(1)}}{{/}}

That tooks just most right element of the Impact and Likelihood value and do simple multiplication. For exmaple Impact is Moderate - 3 and Likelihood is Likely - 4 gives us Risk score of 3x4=12. And If Risk score is 12, it get the Risk level of "High". But somehow, if the Impact and Likelihood has the same number value, like 4 and 4, I get though my Risk number but not the associated Risk level. If the Impact and Likelihood has different number value, like 2 and 5, it works all fine.

Here is my 2 automation rules. First, residual risk score calculation:

residual score calculation.PNG

and risk score allocation/ association:

residual risk level allocationt.png

Basically, If the calculated risk score is between 1 and 4 then risk level is "Low" and if it is between 5 and 9 then risk level is "Medium" and so on.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud