Automation: Populate start/due date from Spring Information

[David Leal]

This would be the logic. My plan is to trigger this rule by schedule, just at the end of the PI Planning. The idea would be:

1. If for the issue, the start/due date is empty and sprint field is not empty, then
2. If the issue has any active sprint, then get the information from there. If there is no active sprint, then take the information from future sprint. For example the one with the earlier start and end dates (the following sprint scheduled to start). Since Jira allows to assign more than one sprint, we need to consider this I would say.
3. Get the start date and end date from the selected sprint
4. Assign it to start/due date fields respectively from the issue

Jira REST API in the JSON file provides information about the sprints:

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

here is the JSON portion where the sprint information is provided for a given issue. For my jira instance the sprint information is represented by custom field 10020:

"customfield_10020": [
{
"id": 787,
"name": "Devas - Sprint 3",
"state": "active",
"boardId": 304,
"goal": "",
"startDate": "2023-02-15T05:00:39.637Z",
"endDate": "2023-03-01T04:59:00.000Z"
},
{
"id": 772,
"name": "Zeus - Sprint 8",
"state": "closed",
"boardId": 304,
"goal": "",
"startDate": "2023-01-05T05:00:00.000Z",
"endDate": "2023-01-13T22:00:00.000Z",
"completeDate": "2023-01-13T23:57:56.313Z"
},
{
"id": 765,
"name": "Devas - Sprint 1",
"state": "closed",
"boardId": 304,
"goal": "",
"startDate": "2023-01-18T05:00:53.634Z",
"endDate": "2023-01-31T23:00:00.000Z",
"completeDate": "2023-01-31T22:44:37.056Z"
},
{
"id": 766,
"name": "Devas - Sprint 2",
"state": "closed",
"boardId": 304,
"goal": "",
"startDate": "2023-02-01T05:00:20.418Z",
"endDate": "2023-02-15T04:59:00.000Z",
"completeDate": "2023-02-15T14:08:18.664Z"
}
],

so there should be a way to iterate over all the sprints select only active or future if no active sprint and compare the dates and pick the earliest one.

Context: Why I would need this rule? I have the sprint name assigned to my issues. The Roadmap view for Scrum board, shows the planning for issues based on the sprint start/end dates (if start/due date from the issue was not assigned). For a Kanban board the Roadmap shows the information based on start/due date from the issues. I have a Kanban project that has several boards (2-scrum, 1-kanban), because it is a Kanban project the Roadmaps shows the information based on start/due dates, even some issues from the scrum board are assigned to a given sprint (I guess this is by design for Kanban projects even though they can define Scrum boards). For epics I have populated start/due dates using date sync feature from Easy Agile Program, so I can visualize the planning at epic level, but not at issue level. That is why I am wondering if I can use Automation to populate start/due dates based on Sprint information for all the issues that have non-empty the sprint field.

Here is my attempt to build a rule:

sprint is defined as follows:

• Smart Value. {{customfield_10020}}
• Variable name: sprint

minStartDate is defined as follows:

• Smart Value: {{#customfield_10020}}{{ if(equals(status, "future")) }}{{/}}.startDate.split(",").min

I got some ideas, on similar situation. What I pretend with the above formula (but I am a beginner with automation) is:

1. From the list of customfield_10020 which is the custom field where the Sprint information is stored in my Jira instance. I am using an if condition to filter the list by status equal to "future" only.
2. For the filtered list, I am going to get the startDate and use split to find the minimum.

and similarly minEndDate is defined as follows:

• Smart Value: {{#customfield_10020}}{{ if(equals(status, "future")) }}{{/}}.endDate.split(",").min

I tested the rule with an issue that doesn't have an active sprint assigned and only one future sprint. Here is the log result:

The advanced compare condition, doesn't match

Thanks for any help,

David

[David Leal · Accepted solution]

I had several errors or mistakes in my initial approach:

• I used status, but the field is state.
• I though the brach can have multiple conditions, but doesn't happen, so after re-fetch, the next condition: start date is empty is never reached, so I need to create a second branch. It looks to me inefficient, but it seems this is the way it works, unless there is another way to do it.
• The condition to find the minimum start date and end date of the future sprints, I could not make it works. I generated an log entry to test it and it doesn't return the expected value, I tried several options and in most of them it returns empty string.
• I realized, but I am not sure, that you can only assign an issue to one future sprint, therefore I don't need to deal with the min function, but anyway it should work for a single value, but as I said could not make it work.

Based on previous comments, this is the rule that works, but maybe there are better ways to do it.

where the start/due dates are assigned respectively as follows:

{{sprintInfo.startDate.jiraDate}}

{{sprintInfo.endDate.jiraDate}}

[Bill Sheboy]

Hi @David Leal 

What does your testing show for the results of the above rule?  I am asking because I hypothesize some unpredictable results...

Branches on one-and-only-one thing (e.g., Current Issue, or Parent (Epic), etc.) get run in-line, and so the rule proceeds on the order of the steps you define, as if there was no branch.

However...branches on things which could have more than one value  (e.g., Advanced branch, JQL, sub-tasks, etc.) are run in parallel and asynchronously.  There is no guarantee when the branch will complete, up to the point of the end of the rule.

And so for your rule with two advanced branches, the branch items could run in any order, potentially overlapping in time.  Without seeing the source of your advanced branch information it is unclear to determine if the Start Date and Due Date fields could be repeatedly set/walked over in values.

A possible work-around for your use case would be to use a single advanced branch, with if/else structures inside to handle the different cases of the Sprints' state.

I also recall trying to solve this use case before, using smart value, list filtering and created variables.  If I find something on that I will post the link to it.

Kind regards,
Bill

[David Leal]

Thanks @Bill Sheboy it makes sense, in my case it worked, I trigger it manually with an issue that has just a single future sprint assigned. Initially I tried to have everything in an a single advanced branch, but it didn't work, because inside the Advance Branch you can add only add: New Action and New Condition, and the New Condition doesn't have an if-else block, so each condition you add runs one after the other. This is what I experienced. In my question I provided the screenshot with a single Advanced Branch, but it didn't work, since my issue has only one future sprint, the first comparison failed (no active sprint), then it didn't continue. Thanks for any help.

[Bill Sheboy]

Gotcha; there was a "feature" which allowed creating if/else outside of a branch, and then dragging that inside, but I believe that may have been fixed.

The other work-around is to put the if/else conditions first, using smart value, list filtering to find matching sprints for the state.  Then have a branch inside of each if condition, based on state:

• if/else condition
  • advanced compare condition: use smart value, list filtering to find sprints for "active:
  • branch: over those values
    • actions to update the dates accordingly
• else-if
  • advanced compare condition: use smart value, list filtering to find sprints for "future:
  • branch: over those values
    • actions to update the dates accordingly

I haven't tried that, although I suspect it will work.

[David Leal]

Thanks @Bill Sheboy I guess I was able to follow you. I tested and it worked. For the advanced compared condition I obtained the list of states, then join it, and using the condition contains to find either active or future. That was my understanding from your recommendation, but may you had in mind something different or simpler.

Here is the rule:

Thanks!

[Bill Sheboy]

Well done! 

The variation I was suggesting was to prune the list of sprints (using list filtering) so the advance branches only walk what you want: active or future sprints.

[David Leal]

Thanks @Bill Sheboy I guess you mean Filtering smart value lists, but the example provided is for taking an specific action, for example extracting a specific field if the condition matches:

{{#issue.comments}}
  {{ if(isInternal, body) }}
{{/}}

but I think what we really want is a subset (a truly filter), I don't know if smart values provide such functionality. Something like this operator, you have in other languages:

{{#customfield_10020}}{{ if(equals(state, active))}}#this{{/}}

so the filter function will return the list elements of customfield_10020 with a given state. Based on the sample provided, I don't know how to do it. Thanks!

[Bill Sheboy]

Yes, you are quite close with your second expression.  Here is an example to filter the advanced branch to only cover the active sprint(s) for the current issue.

The text version of that is:

{{#issue.sprint}}{{#if(equals(state,"active"))}}{{.}}{{/}}{{/}}

[David Leal]

@Bill Sheboy it worked, thanks so much!!!