Automation Rule for multi condition multi values to set.

Shadd Schutte October 14, 2024

I am working on an automation rule that will used the planned start and planned end dates to determine the Program Increment that an epic is aligned with. An epic could start in one Program Increment and end in another Program Increment, and I want to select both values. The field Program Increment is a multi-select field. The planned start is customfield_10101 and planned end is customfield_10102. The logic is working for the most part. 

I am using If/Else statements to determine if the start date is after a specific date or the end date is before a certain date if it is select a specific PI from our list of options. This works but is only selecting the PI for the latest End date.

An example is I have and Epic that has a planned start in the middle of Program Increment PI2 2024 and a planned end date in early part of Program Increment PI3 2024. This epic is only getting set to PI3 2024 when I want it to select both PI2 and PI3.

2 answers

0 votes
Shadd Schutte October 14, 2024

Wrong window

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 14, 2024

Hi @Shadd Schutte 

Rather than the JSON (with may not work due to field differences), please post images of the following for context:

  • an image of your complete automation rule, in one single image; that may require using a screen capture tool or browser addon for scrolling page capture
  • for any smart value conditions, include images of those
  • an image of the audit log details showing the rule execution which did not work as you expected

Until we see those...

I hypothesize your rule is either:

  1. using contradictory if / else conditions, and / or
  2. the rule updates the issue, but does not perform a re-fetch action before attempting another edit.  (As a result, one of the edits is "walking over" the other.

Seeing your rule details will help to confirm (or exclude) these.  Thanks!

Kind regards,
Bill

Shadd Schutte October 14, 2024

Here is a copy of the log for an Epic that should have PI1 and PI2 2024 just based on the planned Start and Planned End dates.

Automation Rule PI log.jpg

 

Here is the full automation rule sorry for being so long it is 8 increments with repeating logic.

Automation Rule PI full capture.jpg

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 14, 2024

Those rule images are not readable to me as the resolution is too low.  Would you please replace them with higher-res ones?

 

From the audit log image you show, it appears there is only one edit of the issue fields.  Is that correct?

Shadd Schutte October 14, 2024

I hope these are better I had to break it down into a series to make it readable.

PI Rule page 1.jpgPI Rule Page 2.jpgPI Rule Page 3.jpgPI Rule Page 4.jpgPI Rule Page 5.jpgPI Rule Page 6.jpgPI Rule Page 7.jpgPI Rule Page 8.jpgPI Rule Page 9.jpgPI Rule Page 10.jpgPI Rule Page 11.jpgPI Rule Page 12.jpgPI Rule Page 13.jpgPI Rule Page 14.jpgPI Rule Page 15.jpgPI Rule Page 16.jpg

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 14, 2024

Thanks; that helps a bit.  First thing to try:

Those advanced planning, date fields definitely cause challenges in rules.  And, comparisons of date / time values are tricky unless you take total control of them.

When you use the custom fields in the comparisons, force them to an exact format which will be comparable as text with your manually typed in values:

{{issue.customfield_10101.jiraDate}}

{{issue.customfield_10102.jiraDate}}

Those will match what you are typing in for greater than / less than checks.

 

Next, I recommend making a list to confirm the correct order of your conditions will match what you expect...leaving no gaps in the logic.  Then create test cases for each one to exercise your rule.

Shadd Schutte October 15, 2024

@Bill Sheboy thanks I did add the logic for jqlDate for each greater than/less than condition. I do have test cases for each PI as well as for overlapping PI's. With the change to the logic, it is now assigning the PI to the first PI that passes the logic and ignoring all the rest. I may have to come to grips that this may not work without a Jira add-on which are not getting approved at the current time where I work.

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 15, 2024

Unless your program increments (PI) occur on a very predictable schedule, I suspect you are correct about investigating marketplace addons. 

 

Let's assume they are on a predictable schedule...

If I was working on this problem, I would split it into two parts for each date field, and remove all of the conditional logic.  Please see below, where I make some assumptions (in bold below) about the format of your PI value names.

GIVEN an epic exists
AND the PIs occur once per quarter yearly
AND the PI names are in the format PI1 yyyy through PI4 yyyy for each year
AND the Program Increment field is empty
WHEN the value of the Planned Start Date and Planned End Date for the epic are set to values
THEN update the Program Increment field to select any PIs which the Planned Start Date and Planned End Date span

 

And so the rule could use the dates values to build the PI name using the quarter and year:

PI{{issue.customfield_10101.format("q")}} {{issue.customfield_10101.format("yyyy")}}

Do the same for the other date field, customfield_10102, saving those two as variables, named varStartPI and varEndPI.  Then your rule only needs to check if they are the same or different to make the edit using a JSON edit to set the Program Increment field, first confirming the smart value or custom field id for it:

{
"fields" : {
"Program Increment" : [
{ "value": "{{varStartPI}}" }
{{#if(not(equals(varStartPI, varEndPI)))}}
, { "value": "{{varEndPI}}" }
{{/}}
]
}
}

This uses conditional logic to either select one or two values in the field.

 

With this approach, your rule would only be a few steps (as compared to using conditions):

  • trigger: field value changes for Planned Start or Planned End
  • condition: issue type equals Epic
  • condition: Planned Start does not equal empty
  • condition: Planned End does not equal empty
  • action: create variable varStartPI for the first field
  • action: create variable varEndPI for the second field
  • action: edit issue, setting the Program Increment using JSON

 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events