Why can't I create a sprint when one is already active?

[Max Waterman (Max)]

I can understand not being able to *start* a sprint when one is already active, but I can't see why I can't create one.

Essentially, I want to start planning the sprint by moving issues out of the backlog into the new sprint, and creating new issues - the objective is to reduce the time taken up by planning meetings.

[Bob Swift · Accepted solution]

See my comment on the other question you posted

[Rick Trudeau]

Thanks Bob, and or the sake of completeness, I'll post your answer here:

"You can have a transition that does not actually change the state and associate any post functions you like including create on transition plugin post function to add one or more subtasks"

So if I understand your suggestion correctly, I would create a workflow transition from State1 to State1, and bind a post function to it that would trigger the creation of the subtasks. That way a user could select the transition from the menu and have the tasks auto-created?

[Bob Swift]

Yes. A create sub task post function for each subtask you want.

[Rick Trudeau]

Yes, thanks again. I think that will work.

One gotcha I'm running into is that when creating the subtask I want to copy to it some custom field values from the parent issue. What I'm finding is that when I try to get to the parent object from within the subTask post function context, I get a null returned. I'm guessing that the binding of the parent to the subTask probably isn't complete until after the subTask is created?

So maybe I need a primary post function to first create the subtask and then a secondary post function to go and modify the created subtask?

[Rick Trudeau]

Another gotcha related to the Post Function that creates a subtask...wondering if anyone has any ideas.

We use GreenHopper to make use of its Ranking capability. When I use the native "Create Subtask" function from an issue, the subtask is created and it takes a rank of (parentIssueRank +1) so that the rank of subtasks always follow the rank of the parent backlog. However, if I use the post function to create a subtask, it looks like the newly created subtask takes the rank of the parent issue and the parent issue gets bumped down, leaving the subtask with a higher rank than the parent issue. This has the unwanted side effect of issues and subtasks not being properly sorted in the GreenHopper Agile view.

Does anyone have any experience with this? Is it possible to have the post function use the same ranking mechanism as the native "create subtask" menu item?

[Bob Swift]

Probably needs an improvement for the Create on Transition plugin. Write one up and I will investigate.

[Rick Trudeau]

Thanks Bob, I went ahead and created: https://studio.plugins.atlassian.com/browse/CSOT-14