Details
-
Suggestion
-
Resolution: Duplicate
-
None
Description
We could add these components
- Action to start / close / edit / create a Sprint
- Sprint overdue (past end-date) trigger
When an issue is edited and the field is Sprint.
- Was it being added/removed.
- Smart values on the Sprint
You currently can set the sprint to copy from parent, current sprint, next sprint, but you can't set it to a particular value
- Next sprint is non deterministic when parallel sprints is enabled
- Sprint.state doesn't return the state that you see in the rest view and the docs on sprint are lacking - For eg, the docs don't mention issue.sprint.isClosed, issue.sprint.isStarted.
We should include some docs around the available values for Sprints and fix access to the state property. - Make "Triggering sprint" as a selectable option for the Sprint field -
Workaround is for when you're using the Sprint related trigger, you can set your Sprint field in the issue to be:{{sprint.id}}
- Provide access to the active sprint via smart values when trigger isn't sprint related
- Issue condition to support actual values in sprint field
- Add Clone Sprint option for variable 'Current Project' -
Sample use case: There is a transition for tickets that resolve a development item as 'Deferred' and clones the same ticket into the next sprint. Since a ticket can't be in 2 sprints at the same time, we keep a resolved place holder in the original sprint to satiate reporting, and a clone to account for this item in the new sprint. We do this through an automation rule.
On the clone action, we set the Project to 'Same Project', but for setting the sprint there isn't a directly similar option.
You have the ability to set the Sprint value; the options are Active Sprint(project A) , Active Sprint(project B), Active Sprint(project C)... or Next Sprint(project A), Next Sprint(project B), Next Sprint(project C)... but you have to define a single project/board for the sprint.
We'd like an option along the lines of Next Sprint('current project'), so that we don't have to define a unique condition step for each Project A, B & C tickets when building a global rule.
Typically, the active sprint is the first sprint:
{{issue.sprint.first}}
But this is not always the case. e.g.
{{issue.Sprint.started}}
Can produce - false, false, false, true, false, false, false, false, false, false, false
We should expose active sprint directly:
{{issue.sprint.active}}
Attachments
Issue Links
- duplicates
-
JRACLOUD-80718 DevOps Automation: More ways to work with sprints: set sprint to sprint ID, sprint name, "triggering sprint"; smart values for active sprint or next sprint, trigger on sprint scope change, new actions/triggers for sprints
- Gathering Interest