Max and min of versioned incidents

[Leonardo Zevallos Guzman]

Hello community, I need help with an automation.
I have many user stories and one epic that belong to a version "x". User stories are not related to that epic by parent/child or linkage. So what I want is that when I edit the start and end dates of the user stories that belong to version "x". That epic that belongs to version "x" captures the lowest value of the start date of all the user stories that belong to version "x" and the highest value of the end date of the user stories that belong to the version "x"

[Bill Sheboy · Accepted solution]

Hi @Leonardo Zevallos Guzman 

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected.  Those will provide context for the community to offer ideas.  Thanks!

Until we see those...

Your rule is probably triggered on a change to the Start Date or Due Date fields, followed by a condition to check if the issue type is a Story.

Once that occurs, your rule could use the Lookup Issues action with JQL to gather all Stories with the same version.  Then the rule could branch with JQL to the Epic which has the same version, and then make the edit, using the min and max functions on the lookup results.

Please review this documentation to learn more about that action and the functions needed:

• https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.min
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.max

Kind regards,
Bill

[Leonardo Zevallos Guzman]

Hello dear. I don't understand much of the documentation but I was able to get it this way

 

As you can see, the project where I am executing it is in GF. I consider it a "static" code because I am telling it where it has to do it in the query part and in the branch. Is there a way to make it more "dynamic". For example: automatically detect the project where the rule is triggered and extract all the user stories from that project with version 1.0? Or at the time of the branch that automatically detects the epic of the project that belongs to the version without having to place it specifically? I say this for the reason that I don't want to fill myself with automations for every project I do.

[Bill Sheboy]

Dynamically doing this with the Lookup Issues action, and the JQL branch to find the epics, is what I was suggesting: everything is relative to the trigger issue's project and fix version.

An example rule could be like this:

• trigger: issue field changes for Start Date or Due Date
• condition: issue type equals Story
• condition: fix version is not empty
• any other conditions you need
• action: lookup issues, with JQL to find all stories with the same fix version.  For example...

project = "{{triggerIssue.project.name}}"
 AND fixVersion = "{{triggerIssue.fixVersions.name}}"
 AND issueType = Story

• branch: on JQL to find the epic, with JQL, such as:

project = "{{triggerIssue.project.name}}"
 AND fixVersion = "{{triggerIssue.fixVersions.name}}"
 AND issueType = Epic

• inside of the branch...
  • action: edit issue...
    • setting the Start Date to {{lookupIssues.Start date.min}}
    • setting the Due Date to {{lookupIssues.duedate.max}}

As an observation: a rule like this would be more predictable in behavior if all of the Stories are assigned to the Epic.  Given your current scenario, multiple epics which are assigned to the version would all be updated, even if there are no associated stories to implement them.

[Leonardo Zevallos Guzman]

Hello, I get this audit error:

[Bill Sheboy]

That was my mistake, which I corrected in the earlier post: the comparison in the JQL should be to {{triggerIssue.project.name}}

The reason is sometimes automation smart values use the default field / attribute (e.g., the key for an issue) and sometimes they return the entire object.  In this case, it appears to return the Project object.  Specifically selecting the name attribute should help.

[Leonardo Zevallos Guzman]

Hello dear.
Now I get this error in the audit:

[Bill Sheboy]

One of the challenges with smart values is the are often slightly different than the field names used in JQL...

in JQL fixVersion is used and in the smart values, it is plural: fixVersions

Please change your two JQL statements to use this:

{{triggerIssue.fixVersions.name}}

And please note: this will work if you have one, and only one, value in Fix Version.  If you have multiple, please let me know so we can make an adjustment.

[Leonardo Zevallos Guzman]

In fixVersion I can handle up to 5 versions: "Version 1.0","Version 2.0","Version 3.0","Version 4.0" and "Version 5.0". Would the jql code change?

[Bill Sheboy]

Yes, the JQL would change to handle a list of versions, to use the IN operator versus the equals = operator

Before making that change, would you please clarify your scenario?

Fix Version is normally associated to a release version, even though Jira allows multiple values in the Fix Version field for cases like multiple products released in production to implement a single story (e.g., multiple platforms).

And you want to update Epic date fields, based on the stories' versions (not the parent / child relationships).  With the addition of multiple versions in the stories' Fix Version field, would there also be multiple Epics to update? 

When one story have a version incorrect, this could update multiple other Epics incorrectly due to the chaining between issues and versions.  Is this understood?

If that is acceptable, the change would be replacing 

 AND fixVersion = "{{triggerIssue.fixVersions.name}}"

With this, using list iteration 

 AND fixVersion IN ( {{#triggerIssue.fixVersions}}"{{name}}"{{^last}}, {{/}}{{/}} )

[Leonardo Zevallos Guzman]

My case is the following, I will have an epic that is like the "information sender" from my project A to my project B. I use the versions to have better traceability of a project. The projects in my work are not complex, they usually take 3 or 4 months to develop. When I create my initial project I will configure the epics and their respective user stories. Only the receiving epic will belong to version 1, the initial user stories will also be version 1. When there is an improvement I will create another epic, I will name it version 2, and the new user stories will also belong to version 2 and so on. no matter how many improvements it has. It should be noted that the receiving epics do not have daughter user stories, they only serve as the means to transfer information. User stories can belong to epics but I will not place these epics in any version. User stories can only belong to one version at a time.

just as shown in the picture:

[Bill Sheboy]

Based on that, there are multiple versions for the project.  Epics and Stories can only have one version value in their Fix Version field.

Issue    Version 1.0  Version 2.0
=======  ===========  ===========
Epic A        X
Story 1       X
Story 2       X
Epic B                     X
Story 3                    X
Story 4                    X

If this is correct, you could use either JQL example I suggested, for one value or multiple values.

[Leonardo Zevallos Guzman]

Yes, the initial query that you gave me helped me. Thank you

[Gerald]

@Bill Sheboy  great!!!