Automation to Update Start and Due dates based on Sprint Dates

[Nick Brotherton]

Hello,

I'm attempting to reuse Automation logic from THIS Atlassian thread. However - it does not seem to return the current sprint values if it has been in a previous sprint.

In the screen shot, you can see that it has added 11/19/24 and 11/25/24 as the values. Yet, 11/25/24 and 12/9/24 should be the values from sprint 19.

How should I refine the logic from the linked article to assure we are getting the active sprint values?

[Bill Sheboy]

Hi @Nick Brotherton 

For a question like this, context is important for the community to help.  Please post the following:

• what type of project is this (e.g., company-managed, team-managed, etc.), 
• 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.

Until we see those...

Next thing, that article is for Jira Server / Data Center, and as you note, does not handle the case of issues in multiple sprints correctly.  Particularly in the unusual case of an issue removed / re-added to the active sprint.

Let's solve this by specifically looking for the "active" sprint.  Assuming we are looking at one single issue, that would be this for the Start Date:

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

And this for the End Date:

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

These work by iterating over the sprint field values, filtering to get the "active" one, and then getting the field needed.

Kind regards,
Bill

[Nick Brotherton]

Thanks Bill! This resolved the issue!

[Nick Brotherton]

Oh sorry - this did not resolve my issue.. User stories in a future sprint are now being ignored.. We're still needing those as they are drivers for our timeline view.

How can I incorporate that into the logic?

[Nick Brotherton]

• what type of project is this (e.g., company-managed, team-managed, etc.), 
  • Team managed
• an image of your complete automation rule,
  • This was identical to the link but now incorporates your logic that need some adjusting
• 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.
  • This logic ideally would include the active sprint or any future sprint

[Bill Sheboy]

Assuming the issue could be in either an "active" or "future" sprint (but not both), you could use the or() function in the filter: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/#or

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

[Trudy Claspill]

Can you share screen images of your entire rule please, and images of individual relevant actions/conditions/branches?

[Nick Brotherton]

Thanks Bill! This has seemed to accomplish what I was attempting to create!

I really wish there was a better platform to write smart value logic haha. It's tough that it's so particular and there' isn't anything to steer you except documentation and the community. Would love a prompt engine feature or something.

[Nick Brotherton]

Hi @Bill Sheboy  - First, thank you again for all the guidance here. VERY much appreciated!

I noticed today that dates are wiped when the sprint field looks like this. 1) I'm unclear why there would be "None" there when it was completed in a sprint.. 2) How should I address this logically to make sure it is accounting for these instances?

[Bill Sheboy]

That view of the Sprint field indicates the issue is not currently assigned to an active sprint, and it has been in two, prior completed sprints.

You note the issue completed in a sprint; did that issue:

• complete during one of those sprints; or
• was it removed / carried over as incomplete, and then marked as "done" whilst in the backlog; or
• something else?

The issue history will help clarify what happened.

I believe you originally only wanted to handle active and future sprints, not completed ones.  What should happen for this case?

[Nick Brotherton]

It was completed in an active sprint, then the sprint was closed. It had dates originally (added manually) then the automation picked up the "none" and removed the dates :( 

I'm uncertain on why I'm seeing "none" tbh

Attached is the sprint report

Originally only needed to address active and future sprints as all past dates were already added.

With a lack of a better way to put it, the dates should be the max dates for whatever sprint they have associated, and ignore any "nones." Hope that makes sense..

[Trudy Claspill]

The field shows "None" to indicate the issue is not currently in an active or planned sprint. The +2 is used to indicate it was included (and not removed) in 2 sprints that have already been completed.

[Bill Sheboy]

That "None" indicator causes lots of confusion, and I recall several suggestions to do something about it.  Regardless...

Getting the max dates from sprints is easy: {{issue.sprint.startDate.max}} and {{issue.sprint.endDate.max}}  But that may not help if they are found at the wrong time / conditions.

Let's pin down the scenario to clarify and resolve this:

• When do you want to set the Start Date and Due Date fields in an issue: sprint started, issue completed, etc.?
• Are there exceptions when the dates would be changed?
• Do the dates need to be set for any issues from before the rule is created?

Knowing these things will clarify the correct rule trigger and criteria used to find the dates.

And, let's not rely on "your rule is the same as that linked article...".  To solve this, we'll need to see images of your actual complete rule and audit log details showing the rule execution.

[Nick Brotherton]

Hi Bill,

Our business case here is to keep said dates current with the sprint they are in. Completed (In theory, once set - should not need readdressing), Current (should have automation to keep current), and Future (should have automation to keep current).

So put a different way - I only want to update the dates when it has been iterated into a sprint in some capacity. And should not remove or dates based on "None."

"When do you want to set the Start Date and Due Date fields in an issue: sprint started, issue completed, etc.?"

• When it is iterated to a sprint.

Are there exceptions when the dates would be changed?

• There are no exceptions for the dates to change. The end goal is to accomplish the logic I refer to in THIS question..

Do the dates need to be set for any issues from before the rule is created?

• Yes now that these dates have been removed, I will need to populate them again haha. But it seems like the min/max logic you provided may address this.

Here is a screenshot of the logic I have. Below is the logic in the issue fields

Start date: {{#issue.sprint}}{{#if(or(equals(state,"active"), equals(state,"future")))}}{{startDate}}{{/}}{{/}}

Due date: {{#issue.sprint}}{{#if(or(equals(state,"active"), equals(state,"future")))}}{{endDate}}{{/}}{{/}}

Going to pause on updating the logic on min max until I hear back from ya

[Bill Sheboy]

Great; thanks for clarifying!

Other than "oops" situations, the rule you show will handle issues added to an Active Sprint or a Future Sprint.  For safety, I recommend adding one more condition after the trigger to check the status is not "Done" (or whatever you use for "completed").

To clean-up / fix completed issues' dates, first you need to decide which ones to update.  I recommend performing some JQL searches outside of rules to find them first.

Once found, a second scheduled trigger rule with that JQL could be used to make the updates.  The JQL will need some form of "stopping condition" to halt when done, such as a field value or using the updated date/time stamp.  As there may be more than 100 issues, you could let the rule run until it is caught up, and then disable it.

For the date values, an assumption could be: the issue completed in the last sprint it was assigned to.  If that is a valid assumption, the dates would be the maximums for each issue: {{issue.sprint.startDate.max}} and {{issue.sprint.endDate.max}}

[Trudy Claspill]

Hello @Nick Brotherton 

Please notice that the KB says it is for Jira Server and Data Center only. Automation functionality may not work the same on Jira Cloud.

Can you provide screen images that show your entire rule and the details of each step, please, so that we can double check for deviations from the example in the KB?